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FOREWORD 

The  course  in  which  you  are  about  to  participate,  entitled  “Introduction  to 
Program  Management,”  and  this  accompanying  handbook  are  intended  to  provide 
you  with  an  awareness  of  the  scope  and  importance  of  program  management  at 
the  Naval  Ocean  Systems  Center  and  to  impart  to  you  the  management 
philosophies  that  I  believe  will  be  important  to  your  success,  individual 
development,  and  career  growth. 

» 

It  is  my  belief  that  NOSC  is  a  key  part  of  the  Navy’s  Systems  Acquisition  Team 
and  that  our  Center’s  reputation  depends  on  the  capabilities  of  our  program 
managers.  Therefore,  it  is  imperative  that  each  individual  charged  with  program 
management  responsibilities  discharges  those  responsibilities  in  a  way  that  fulfills 
DoD  and  Navy  statutory  requirements  and  ensures  that  the  Navy  receives  the 
maximum  benefit  from  its  investment.  In  addition  to  these  legalistic  requirements, 
we  must  operate  with  efficiency  and  complete  integrity.  And,  while  it  is  a  well- 
worn  phrase,  it  really  is  often  our  responsibility  to  ensure  that  the  Navy  is  able  to 
operate  as  a  “smart  buyer"  in  a  very  complicated  and  highly  technical  market 
place.  In  the  final  analysis,  we  have  succeeded  only  if  we  provide  the  Navy  with 
effective  and  affordable  timely  solutions  and  capabilities  that  are  superior  to  those 
of  the  threat. 

It  is  my  intent  that  this  course  provide  the  framework  for  training  new  and 
potential  program  managers  as  well  as  establishing  a  standard  by  which 
functioning  program  managers  can  measure  themselves.  Because  this  course  and 
handbook  are  directed  toward  program  management  as  it  is  accomplished  at  the 
Naval  Ocean  Systems  Center,  your  feedback  on  the  course  and  supporting 
documentation  is  encouraged.  As  the  need  arises,  this  course  and  document  will 
be  updated  to  reflect  changes  in  the  program  management  environment  as  well  as 
changes  in  statutory  law  governing  the  methods  of  accomplishing  our  business. 
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SECTION  1 

EXECUTIVE  SUMMARY 


1.1  PURPOSE 

The  NOSC  Program  Managers  Handbook  is  designed  as  a  ready  reference  document  for  those  who 
have  taken  the  NOSC  course,9  "Introduction  tpJgrograro^Management.^It  is  not  intended  to  be  a 
thorough  examination  of  each  topic.  However,  the  handbook  provides  its  user  with  basic  information 
regarding  the  topic  along  with  some  references  and  resources,  including  NOSC  instructions  and  other 
applicable  documentation.  It  also  provides  guidance  for  program  managers*as  they  carry  out  their 
varied  functions,  and  gives  examples  of  the  forms  or  requirements  that  accompany  particular  activities. 

The  target  audience  for  this  handbook  is  a  group  of  interested,  skilled,  and  experienced  program  / 
managers  who  know  what  it  is  like  to  manage  a  program  in  the  reai  world.  Perhaps  the  thought  has 
occurred  to  them  that  the  “system”  does  not  work.  Perhaps  their  experience  has  reflected  the  following 
six  phases  of  a  project: 

Enthusiasm 

Disillusionment 

Panic 

Search  for  the  Guilty 

Punishment  of  the  Innocent 

Praise  and  Honors  for  the  Nonparticipants. 

However,  part  of  the  purpose  of  this  handbook  is  to  demonstrate  that  the  “system”  does  work  when 
implemented  by  skilled  program  managers.  Center  management  provides  policy  and  guidance  certainly, 
but  it  is  the  task  and  responsibility  of  program  managers  to  implement  the  guidance  and  policy,  that 
is,  to  make  the  “system”  work.  It  is  hoped  that  the  users  of  the  handbook  will  be  those  successful 
managers. 

‘  TSr.  " 

1.2  ORGANIZATION 

The  NOSC  Program  Managers  Handbook  contains  an  executive  summary  and  sections  for  each 
of  the  18  topics  addressed  during  the  management  course: 

? — Section— h  Executive  Summary; 

-V  Section  2.  How  Projects  Originate  and  Develop ) 

-  Section  3.  Program  Management  Functions  and  Responsibilities  , 

>  Section  4.  Proposal  Development  and  Marketing; 

Section  5.  Staffing,  Team  Building,  and  Communication; 

Section  6.  Major  Systems  Acquisition,' 

Section  7.  Planning,  Scheduling,  and  Assessment  j  — - )  . ,  .  •*'! 

•While  »he  term  "program  managers"  has  a  particular  DoD  denotation,  in  this  handbook  the  term  is  used  in  a  broad  sense 
and  includes  program,  project,  and  product  managers. 


. . s  *...v.;v_ ^v,ss^±r*irjjru]cijr^yc~rr*.'rmr*.’ iuiiw.xjliw ht. ».- aaa^<vjs.-jw. 


\ 

>.,.  \ 

iSection'TO. 
Sectional  1. 
Section  15. 
^Section  13. 

Secdonl4. 

\  > 

Section  15. 
Section '16.. 


Section  \§. 
Section  9. 


Section  17. 
•Sectional  8. 
Section  19. 

'  ''N., 


Systems  Engineering', 
Contracting ; 

Financial  Management^ 

Human  Factors  - 
Design  Review; 

Hardware  Product  Assurance , 
Software  Product  Assurance; 
Test  and  Evaluation; 

Technical  Informat  ion  Support  j 
Computerized  As  .isitnce  ; 
Computer-Aided  ;  gistics, 
Follow-On  Training  , 


1.3  FORMAT 

Apart  fro-s  the  executive  summary,  each  of  the  sections  follows  a  general,  numbered  outline.  That 
numbered  outi*.' .  depends  f‘rst  on  the  section  number  (2  through  19).  The  first  subsection  (X.l)  is 
always  the  i?i>  Auction.  i- r  o; ::  that  point  on,  the  outline  is  unique  for  each  section. 


1.4  AN  INVITATION 


This  handbook  is  a  document  in  process.  As  such  it  will  be  constantly  updated  and  revised  to 
reflect  the  latest  information  and  thought  in  each  of  the  topic  areas.  If  contributors  wish  to  revise  and 
extend  their  remark; .  key  are  inviied  to  do  so.  If  any  of  the  participants  has  suggestions  on  how  to 
improve  the  handbook  or  ideas  on  how  the  material  could  be  more  effectively  presented,  please  contact 
the  cognizant  personnel.  Any  constructive  counsel  is  welcome. 


1.5  ACKNOWLEDGMENTS 

Grateful  than!  s  are  extended  to  the  session  leaders  for  the  time  and  effort  expended  in  preparing 
their  presentations.  Each  one  of  them  is  a  volunteer  who  thought  that  the  topic  was  significant,  that 
it  deserved  airing  in  front  or  Center  program  managers,  and  that  NOSC  would  perform  its  mission 
better  with  better  informed  program  managers. 
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SECTION  2 

HOW  PROJECTS  ORIGINATE  AND  DEVELOP 


2.1  INTRODUCTION 


2.1.1  References 

Navy  Program  Manager’s  Guide,  1985 
Navy  RDT&E  Management  Guide,  NAVSOP-2451 
NOSC  Planning  Calendar,  NOSC  TD  1189 
NOSC  Program  Planning  Guidance  Memorandum 

The  Planning,  Programming,  and  Budgeting  System  (PPBS)  Course  Materials,  Office  of  the 
Director,  DON  Program  Information  Center  (26  June  1985),  Washington,  DC  20350. 
DoDI  5000.2  and  DoDI  5000.3 
SECNAVINST  5000.1 
OPNAVINST  5000.42 

NOSC  Memo  013/49-85,  Policy  and  Procedures  for  FY86  IR  Program,  of  20  March  1985 
NOSC  Memo  014/173-85,  FY86  IED  Proposals,  of  9  August  1985 

NOSC  Memo  021/21-85,  Information  on  Major  Bid  and  Proposal  (MB&P)  Program,  of  18 
September  1985 


2.1.2  Summary 

Projects  originate  from  military  needs  which  arise  from  changes  in  threat  or  in  tactics,  from  the 
need  to  replace  obsolete  equipment,  and  from  technological  innovations  that  promise  to  address  military 
needs.  Operationally  inspired  needs  are  documented  by  formal  requirements  documents.  The  process 
for  transforming  the  needs  into  requirements  also  identifies  funding  that  formally  initiates  the  pi  oject. 
Technology-originated  projects  are  initiated  through  ongoing  technology  programs  that  address 
contif’ung  military  needs.  Technology  programs  include  Block  Programs,  independent  research  (IR) 
programs,  independent  exploratory  development  (IED)  programs,  product  improvement  programs, 
and  mission  area  support  programs.  Projects  in  the  technology  base  are  normally  justified  against  the 
program  charter. 


2.2  GENERAL 

The  conduct  of  research  and  development  is  focused  upon  meeting  Fleet  needs  in  the  near  term 
and  distant  future.  Because  resources  are  limited  and  needs  can  arise  with  alarming  suddenness,  careful 
and  responsive  program  origination  and  management  are  required.  This  class  session  will  offer  a  brief 
overview  of  the  existing  organizations  and  processes  employed  in  Navy  research,  development,  test, 
and  evaluation. 
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While  Fleet  needs  and  deficiencies  are  topics  of  semiannual  messages  to  and  from  Fleet  commanders, 
they  are  the  constant  topics  of  discussion  throughout  the  Navy,  Marine  Corps,  and  Coast  Guard.  Arising 
threats,  new  mission  roles,  obsolescence  of  existing  capabilities  and  equipment,  technology  breakthroughs 
and  maturation,  and  the  needs  posed  by  joint-force  operations  and  foreign-sales  demands,  all  affect 
initiation,  scope,  and  direction  of  research  and  development  efforts. 


In  our  age  of  technology  where  so  much  can  be  done,  the  matter  of  choice  in  applications  engineering 
is  crucial  to  national  defense.  The  use  of  ancient  simple  weapons  was  extensive  and  long-lived.  Modern 
weapons  systems  are  tailormade  to  exploit  a  diminishing  set  of  target  vulnerabilities  and  countermeasures, 
and  so  are  more  expensive  to  field  and  of  shorter  use  against  a  responsive  threat  organization. 


In  efforts  to  respond  to  changes  in  world  and  national  circumstances,  maritime  strategies  and  U.S. 
Navy  roles  and  objectives  can  also  change  in  function,  scope,  and  priority.  National  requirements  for 
purposes  of  “presence,”  “sea  control,”  and  “projections  of  force,”  etc.,  shift  in  emphasis.  Balance 
cf  appropriate  roles  and  strengths  among  our  armed  forces  also  affects  R&D  objectives,  resources, 
and  the  economics  and  use  of  logistics. 


Timing  is  as  essential  in  RDT&E  as  it  is  in  the  capability  and  technology  choices;  seldom  is  cost 
not  a  governor  of  the  process.  Because  resource  needs  normally  exceed  resources,  the  Navy  employs 
an  advocacy  system  in  OPNAV  and  between  the  services  in  DoD  to  hammer  out  the  Five-Year  Defense 
Program  (FYDP).  The  unfortunate  feature  of  the  process  is  that  there  is  the  need  for  an  almost  constant, 
urgent  defense  of  proposals  against  often  worthy  alternatives,  all  of  which  may  be  valid  and  timely 
options. 


The  material  for  this  overview  of  RDT&E  program  management  has  been  drawn  largely  from 
two  documents: 


The  Navy  Program  Manager’s  Guide,  1985  edition  NAVMAT  P-9494  (NOSC  Library  Accession 
110582) 


b.  The  Planning,  Programming,  and  Budgeting  System  (PPBS)  course  materials,  Office  of  the 
Director,  DON  Program  Information  Center  (26  June  1985),  Washington,  DC  20350 


Each  document  refers  the  reader  to  an  extensive  list  of  documents  in  order  to  provide  current 
authoritative  information  addressing  specifics.  The  grand  scheme,  however,  is  apparent  in  a  review 
of  the  major  concepts  and  processes  of  the  organizations  presented  in  these  recent  documents,  each 
of  which  is  subject  to  revision  at  least  annually.  The  Navy  Program  Manager’s  Guide,  for  instance, 
is  in  revision  in  part  because  NAVMAT  no  longer  exists.  The  U.S.  Navy  Postgraduate  School  (NPGS) 
is  the  new  sponsor  for  this  document.  You  will  find  this  source  very  readable  and  useful,  and  so  should 
consider  it  as  a  desk  reference  for  your  program  management  office. 


As  stated  in  the  introduction  to  the  Navy  Program  Manager’s  Guide,  the  purpose  is  to  assist  the 
manager  by  outlining  the  system  acquisition  process,  identifying  participants  and  describing  their  roles, 
describing  the  procedures  necessary  to  move  the  program  from  one  milestone  to  the  next,  and  identifying 
possible  pitfalls  along  the  way.  This  guide  was  prepared  under  direction  of  Dr.  George  Handler  of 
the  Naval  Weapons  Center,  China  Lake,  California.  Because  it  is  so  extensive  and  provides  details 
useful  to  program  managers  in  Navy  laboratories,  as  well  as  in  headquarters  organizations,  it  is  an 
important  text  to  accompany  the  presentation  for  our  topic:  How  Projects  Originate  and  Develop. 


NOSC  program  management  guidance  and  support  are  described  in  an  extensive  sene'-  of  NOSC 
tructions,  directives,  and  notes  kept  current  by  the  various  offices  responsible.  Keeping  current  on 
....  of  these  is  difficult  without  maintaining  a  set  of  current  instructions  in  the  program  office  for  reference. 
Indeed,  setting  up  a  program  office  is  left  to  the  ingenuity  of  the  manager,  though  organization,  files, 
and  operations  should  be  described  in  documents  maintained  for  convenience  and  efficiency  among 
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employees  of  the  office. 

NOSC  memorandums  describing  organization  and  independent  research  (1R),  independent 
exploratory  development  (IED),  and  bid  and  proposal  processes  include  the  following 

NOSC  Memo  013/49-85,  Policy  and  Procedures  for  FY86  IR  Program,  of  20  March  1985 

NOSC  Memo  014/173-85,  FY86  IED  Proposals,  of  9  August  1985 

NOSC  Memo  021/21-85,  Information  on  Major  Bid  and  Proposal  (MB&P)  Program,  of  18 

September  1985 

A  most  useful  NOSC  document,  TD  1189,  is  a  single  page,  poster-size  schedule  summary  for  R&D 
planning  guidance.  The  title  is  NOSC  Planning  Calendar,  and  it  is  updated  annually. 

It  should  be  noted  that  the  involvement  of  NOSC  in  more  responsible  roles  in  major  program 
management  makes  it  desirable  for  aspiring  managers  to  attend  one  or  more  of  the  following  more 
extensive  courses  on  the  subject: 

Defense  Systems  Management  College 

Naval  Material  Career  Development  Institute 

Federal  Acquisition  Institute 

USN  or  Department  of  Defense  PPBS  course  (joint  service  programs  are  also  addressed) 


The  most  important  documents  shaping  current  acquisition  policy  are  Department  of  Defense  Doc. 
5000.1  and  its  implementing  instructions: 

DoDI  5000.2  and  DoDI  5000.3 
SECNAVINST  5000. P 
OPNAVINST  5000.42 

These  are  drafted  addressing  major  programs,  for  which  the  Secretary  of  Defense  chooses  to  act  as 
program  decision  authority  (PDA),  but  each  applies  to  all  lesser  programs  in  principle,  when  tailored 
to  the  nature  and  cost  of  each. 

Generally,  DON  acquisition  policy  calls  for  a  program  initiation  decision  to  be  made  by  the  proper 
program  decision  authority  and  approval  for  program  start  to  be  integrated  with  the  planning, 
programming,  and  budgeting  system  (PPBS).  At  each  subsequent  major  milestone,  the  program  manager 
is  required  to  prepare  milestone  review  documentation  (MRD)  and  have  it  reviewed  and  submitted  to 
the  PDA  for  approval. 

NOSC  program  or  project  managers  are  required  to  provide  documentation  support  for  sponsor 
compliance  with  these  requirements,  together  with  representation  of  technical  work  and  planning. 


2.3  PROJECT  ORIGINATIONS 

Projects  are  initiated  to  respond  to  the  real  or  perceived  needs  of  the  Fleet.  These  needs  arise  from 
new  threats,  from  new  tactics,  from  new  capabilities  of  technology,  and  from  the  obsolescence  of  old 
equipment.  Often  the  Fleet  needs  are  a  combination  of  these  forcing  functions. 

Inherent  in  any  new  threat  is  a  need  to  counter  the  threat.  For  instance,  a  new  enemy  submarine 
might  be  quieter  and  carry  more  lethal  armaments.  This  increases  the  need  to  better  detect  and  track 
enemy  submarines;  it  may  also  increase  the  priorities  of  our  ongoing  programs  to  detect  and  track 
submarines.  Part  of  this  response  might  be  lo  develop  new  tactics  that  improve  our  detection  capabilities. 
Another  response  might  be  to  upgrade  sensor  systems.  We  might  develop  a  new  system  that  can  exploit 
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a  peculiarity  of  the  new  sub’s  design.  We  might  provide  a  new  form  of  command  control  system  to 
provide  a  quicker  response  to  this  new  threat.  Some  new  threats  require  very  comprehensive  responses 
while  others  can  be  countered  effectively  by  relatively  minor  enhancements  to  existing  countermeasures. 
The  total  countermeasure  response  is  not  to  automatically  develop  new  equipments;  often,  procedural 
changes  in  “tactics”  are  sufficient. 

“New  tactics”  refers  to  more  than  mere  conduct-of-war  procedures  on  the  front  line.  In  the  sense 
used  here,  “tactics”  refers  to  all  organizational  and  procedural  changes  to  the  day-by-day  conduct 
of  the  Navy  profession.  Therefore,  organizational  changes  that  impose  new  responsibilities  on  a 
commander  may  imply  a  need  for  that  commander  to  have  better  decision-making  tools.  New  tactics 
may  be  developed  to  counter  a  perceived  enemy  threat;  this  may  generate  a  need  to  tie  information 
from  diverse  sources  into  one  database.  New  tactics  exploiting  previously  unrecognized  potentials  of 
a  weapons  system  might  increase  the  data-rate  requirements  in  existing  communications  links.  In  other 
words,  “new  tactics”  may  have  implications  for  the  equipment  and  systems  needed  to  support  their 
successful  implementation. 

New  capabilities  of  technology  are  constantly  needed  to  address  emerging  military  needs.  However, 
every  advancement  of  the  state-of-the-art  also  creates  new  needs  in  itself  by  the  mere  potential  of  its 
application.  For  instance,  microelectronic  technology  is  critical  to  adding  more  capabilities  to  existing 
equipment  within  the  same  box.  Indeed,  the  art  of  war  always  has  more  technological  demand.*:  than 
can  be  supported  by  current  technology.  However,  a  breakthrough  in  technology  can  create  a  new 
level  of  threat  to  the  enemy  and  can  enable  more  effective  tactics  to  be  employed.  It  is  usually  the 
technologist  (i.e.,  YOU)  who  recognizes  these  potentials  rather  than  the  operators.  Furthermore,  the 
understanding  of  current  and  future  capabilities  of  technology  is  essential  to  the  assessment  of  future 
threats/tactics.  The  Center’s  charter  includes  a  responsibility  to  conduct  this  assessment  in  the  technology 
areas  for  which  it  has  a  lead  laboratory  role  or  for  which  it  is  a  designated  “center  of  excellence.” 

Regardless  of  the  merit  of  a  new  idea,  a  newly  recognized  need,  or  the  continual  seriousness  of 
a  problem,  the  GEE-  WHIZ  phenomenon  is  often  exploited  to  get  the  project  approved,  to  get  the  need 
recognized  as  a  formal  requirement.  The  GEE-WHIZ  phenomenon  is  nothing  more  than  the  appeal 
of  “the  latest”  technology.  The  military  art  is  so  dependent  upon  technological  advancements  that 
the  habit  of  this  dependency  takes  on  meaning  of  its  own.  Thus,  a  given  approach  to  a  problem  may 
be  entirely  satisfactory  in  all  aspects  for  the  past  30  years  and  into  the  foreseeable  future,  but  a  new 
approach  incorporating  GEE-WHIZ  technology  may  become  an  attractive  alternative  anyway.  The 
phenomenon  exists  as  both  good  and  evil  to  be  wielded  wisely  by  technologists  in  their  task  to  support 
the  Fleet. 

Equipment  has  a  usable  sen/ice  life  which  is  often  shorter  than  the  platforms  (or  commands)  serviced. 
The  long  acquisition  cycle  virtually  guarantees  that  no  operational  system  is  “cutting  edge”  technology. 
Even  when  this  factor  is  not  a  problem,  the  cost  of  ownership  starts  to  rise  rapidly  for  obsolescent 
equipment.  There  is  a  continuing  need  to  replace  such  equipment  or  to  at  least  upgrade  the  equipment 
to  incorporate  up-to-date  technologies  that  can  be  economically  supported.  Other  factors  leading  to 
equipment  replacement/upgrade  include  reliability,  maintainability,  or  logistics/part  support  problems, 
operability/interoperability  features  needed,  survivability  issues,  additional  capabilities,  greater 
performance,  etc.  Whatever  the  source  of  obsolescence  (i.e.,  need  to  upgrade  or  replace),  the  existing 
equipment  provides  a  baseline  to  which  the  needs  can  be  referenced.  Projects  that  have  their  roots 
in  these  needs  are  qualitatively  different  from  projects  originating  from  purely  operational  considerations 
because  the  needs  are  stated  in  technical  terms  (3  dB  more  power,  6  mph  faster,  50  percent  higher 
MTBF,  33  percent  cheaper  to  maintain,  etc.)  rather  than  in  operational  mission  terms. 


In  this  discussion,  you  will  note  that  “needs”  were  identified  rather  than  “requirements.”  This 
is  simply  to  recognize  the  quirk  in  the  Navy  acquisition  system  that  requirements  only  exist  in  formal 
statements  issued  by  OPNAV  when  it  has  attached  funding  to  a  need  and  approved  a  project/program 
to  address  it.  Many  needs  exist  that  will  never  become  formal  requirements.  The  demand  of  “needs” 
always  exceeds  the  resources  available  for  “requirements.”  A  project  does  not  become  initiated  formally 
until  the  REQUIREMENT  exists.  The  process  of  transforming  needs  into  requirements  is  an  art  to 
be  mastered.  How  this  process  occurs  has  a  profound  affect  upon  how  the  project  is  chartered,  funded, 
and  managed  by  you.  The  process  can  result  in  Center  participation  in  one  of  three  ways: 

•  a  project  may  be  directed  to  us 

•  a  project  may  be  offered  to  us 

•  a  project  may  be  proffered  by  us 

The  results  are  different  because  the  persons  responsible  for  providing  the  energy  to  push  the  NEEDS 
through  the  bureaucratic  band-stop  filter  called  the  acquisition  system  are  in  fundamentally  different 
positions  within  that  bureaucracy. 

2.3.1  Directed  Programs 

Directed  programs  occur  when  an  authority  in  the  acquisition  system  directs  the  Center  to  be  involved 
in  a  program.  Invariably,  the  program  enjoys  a  high  priority,  has  high  visibility,  and  has  a  well-established 
need.  An  authority  able  to  direct  the  Center  resources  in  this  way  also  has  the  authority  to  establish 
prioities  and  needs  in  the  acquisition  system  bureaucracy.  High  visibility  occurs  because  of  the  interest 
of  the  directing  party.  There  are  not  very  many  programs  that  might  fall  into  this  catagory  (fewer  than 
1  percent),  because  the  persons  with  such  authority  are  limited  to  the  Chief  of  Naval  Operations  and 
higher  authority. 

When  the  Center  receives  a  directed  program,  the  program  relationships  are  normally  as  follows: 

•  The  laboratory  role  is  well  defined— usually  as  a  technical  consultant. 

•  The  Center  participation  is  directed  because  of  its  charter  responsibilities  and  established  expertise. 

•  Program  participants  might  be  name  requested  or  speci;.ii  >’  selected. 

Usually  the  tasking  is  well  funded,  and  the  schedule  is  very  tight. 

Directed  programs  are  of  special  interest  to  the  Navy,  DoD,  or  the  administration.  The  need  is 
most  often  created  by  administration  priority  goals,  so  a  formal  requirement  statement  may  be  generated 
after  the  fact  of  program  initiation.  The  justifications  for  obtaining  congressional  approval  are  part 
of  the  budget  submission  and  outrank  the  normal  requirements  statements. 

If  directed  to  participate  on  such  a  program,  propose  adequate  resources  to  do  the  required  tasks 
and  to  cover  possible  contingencies.  Directed  programs  are  such  a  high  visibility  that  success  is  demanded. 


2.3.2  Offered  Programs 

Offered  programs  comprise  less  than  10  percent  of  Center  programs  and  are  of  two  types  that 
can  best  be  described  as  follows: 
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•  A  pet  program  of  somebody  who  doesn’t  have  sufficient  authority  to  direct,  only  request,  Center 
participation. 

•  A  program  offered  to  the  Center  because  of  past  performance,  recognized  expertise,  and 
established  working  relationships— even  individual  reputations. 


In  this  first  case,  the  offered  program  has  much  the  same  character  as  a  directed  program,  except  the 
offerer  does  not  have  sufficient  authority  to  direct  the  establishment  of  requirements  and  acquisition 
system  priorities.  Part  of  the  tasking  may  involve  helping  the  offerer  justify  the  program  up  the  chain 
of  command.  This  is  probably  even  more  true  in  the  second  case,  where  the  program  participation 
is  probably  based  on  personal  working  relationships  developed  over  the  years.  The  requirements  are 
usually  not  well  defined  and  the  initial  program  outline  may  not  be  sensible;  part  of  the  task  is  to  bring 
sanity  to  the  program  as  an  expert.  Assume  as  much  responsibility  as  you  can  comfortably.  Ensure 
that  your  tasking  is  adequately  proposed  and  that  contingencies  are  fully  acknowledged,  if  not  fully 
funded.  It  is  normally  up  to  the  Center’s  program  leader  to  obtain  the  big  picture  necessary  to  adequately 
plan  the  program,  justify  requirements,  and  otherwise  fill  out  the  paperwork  to  satisfy  the  bureaucracy. 


2.3.3  Proffered  Programs 


The  proffered  program  originates  with  the  technologist  (you).  You  perceive  the  need,  conceive 
the  good  idea  addressing  that  need,  generate  the  proposal,  help  to  market  the  requirement,  and  otherwise 
assume  the  responsibility  for  driving  the  program  through  to  a  successful  conclusion.  Very  often  this 
can  only  be  done  by  selling  others  that  it  was  their  idea.  Everything  in  your  proposal  is  negotiable, 
but  keep  in  mind  that  it  is  competing  for  scarce  resources.  The  funding  for  directed  programs  is  “fenced” 
(protected)  by  those  in  the  position  to  direct  them,  and  offered  programs  have  a  well-placed  champion 
in  the  system.  Proffered  programs  have  to  be  “sold”  to  a  champion  or  otherwise  justified  so  well  that 
the  management  of  the  acquisition  system  will  grant  them  some  priority.  Good  ideas  seldom,  if  ever, 
sell  themselves  on  their  own  merit;  there  are  simply  too  many  good  ideas  and  not  enough  resources 
to  address  them.  Often  the  good  idea  must  appeal  to  nonaltruistic  motives  of  those  in  acquisition  system 
management  in  order  to  get  approved. 


2.3.4  Program  Justification 


Programs  may  be  justified  by  operationally  recognized  needs  or  by  needs  to  incorporate  new 
technology.  The  document  that  formalizes  needs  into  requirements  is  the  Operational  Requirement 
(OPNAVINST  5000.42).  Certain  small  projects  and  technology  based  programs  do  not  require  an  OR, 
but  they  must  be  justified,  nonetheless.  Anybody  may  draft  an  OR  (even  the  Russian  Embassy)  and 
submit  it  to  OPNAV,  but  the  OPNAV  sponsor  must  see  merit  enough  to  incorporate  the  requirement 
into  the  program  plan.  When  so  received,  the  draft  OR  becomes  a  Tentative  OR  (TOR)  and  funds 
may  be  released  to  prepare  a  development  options  paper  (DOP);  when  the  budget  is  approved  covering 
the  TOR,  the  TOR  becomes  an  OR,  and  the  project  is  formally  initiated. 


Technology  initiated  programs  may  originate  out  of  the  technology  base  programs  (independent 
research/independeni  exploratory  development,  block  programs,  continuing  program  elements,  funded 
technical  investigations,  etc.);  or  from  needs  to  replace  obsolete  equipment  or  from  needs  to  infuse 
new  technology  into  the  art  of  war.  Typically,  the  early  investigations  that  precede  formal  program 
initiation  must  be  funded  and  justified  through  one  of  the  technology  base  programs.  These  are  typically 
limited  to  S200K  annually,  $1M  total.  The  justifications  must  conform  to  the  rules  of  the  program 
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administrator  and  show  support  for  the  stated  purposes  of  the  program.  Formally  established 
requirements  are  necessary  for  technical  or  product  improvements  over  $1M  total  and  for  all  military 
improvements. 

Operationally  initiated  programs  are  established  through  Fleet -generated  draft  ORs  or  through 
Fleet-identified  deficiencies.  (Often  the  Center  is  able  to  find  a  Fleet  champion  for  its  good  ideas  so 
that  the  project  appears  to  be  operationally  initiated.)  Operationally  initiated  programs  are  often  accorded 
a  higher  priority  by  the  acquisition  system  because  support  of  the  Fleet  is  its  primary  charter. 

OPNAVINST  5000.42  provides  all  the  definitions  and  formats  for  documents  required  to  keep 
the  acquisition  system  bureaucracy  fed.  Procedures  are  outlined  for  program  approvals.  A  key  document 
for  every  program  is  the  Test  and  Evaluation  Master  Plan  (TEMP)  (OPNAVINST  3960.10, 
SPAWARINST  3960.3,  NAVSEAINST  3960.2,  and  NAVAIRINST  3960.2).  For  USMC  projects,  see 
MCO  5000.10  and  MCO  5000.1 1.  The  project  manager  should  become  thoroughly  familiar  with  these 
instructions. 


APPENDIX  2A 

NAVAL  OCEAN  SYSTEMS  CENTER  CHARTER  RESPONSIBILITIES 

Mission:  To  be  the  principal  Navy  RDT&E  Center  for  command  and  control,  communications,  ocean 
surveillance,  surface-  and  air-launched  undersea  weapons  systems,  and  submarine  Arctic  warfare. 

Lead  Laboratory  Responsibilities  (and  Block  Program  assignments): 


t 


Ocean  Surveillance 
Lasers  and  Microelectronics 
Communications  and  Networking 
Combat  Direction 
Computer  Technology 
Strategic  Undersea  Surveillance 
Marine  Mammals 
Arctic  Technology 
Deep  Ocean  Technology 


Technology  Leadership  Assignments: 

Multiplatform  command  control  and  communications  (C3)  systems 
Multiplatform  combat  systems  integration 

Ocean  surveillance  (electromagnetic/electrooptic/acoustic  reconnaissance  and  search) 
Deep  ocean  engineering 
Shipboard  internal  communications 
Marine  biosciences 

Environmental  description  and  prediction  for  ocean  surveillance  and  C3 

Surface  ship  ASW  fire  control 

Surface-  and  air-launched  torpedos 

Signals  warfare  and  countermeasures 

Teleoperator  and  remote  presence  systems 

Over-the-horizon  targeting  (OTH-T) 
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SECTION  3 

PROGRAM  MANAGEMENT  FUNCTIONS  AND  RESPONSIBILITIES- 
RELATIONSHIPS  TO  LINE  MANAGEMENT 


3.1  INTRODUCTION 


3.1.1  References 

Navy  Program  Management  Guide,  1985 
NOSC  Program  Planning  Guidance  Memorandum 
NOSC  Instructions  &  Notes 

3.2.2  Summary 

Program/project  managers  have  responsibilities  toward  the  line  management  of  the  organization 
they  are  employed  by  and  toward  the  program  chain-of-command.  These  responsibilities  sometimes 
create  conflicting  demands  that  the  PM  must  resolve.  The  successful  PM  understands  these  demands 
and  the  organizational  systems  that  create  them.  The  keys  to  meeting  these  demands  successfully  are 
RESPONSIVENESS  and  COMMUNICATIONS. 


3.2  GENERAL 

The  establishment,  conduct,  and  conclusion  of  an  RDT&E  program  at  NOSC  presumes  awareness 
and  compliance  with  basic  functions,  forms,  and  communication  standards  imposed  by  the  sponsor 
and  by  local  and  higher  organizational  levels  of  authority  and  resource  allocation.  The  NOSC  independent 
exploratory  development  (IED)  and  technical  base  management  organization  is  shown  in  Figure  3.1. 

Above  all,  the  program  must  fit  in  with  other  efforts.  In  order  to  maintain  support  for  the  program, 
the  sponsor  must  be  given  adequate  results  in  each  component  area.  Most  R&D  programs  are  composites 
of  efforts  at  several  sites  among  industry,  academic,  and  Navy  activities. 

It  is  crucial  that  the  various  program  participants  set  and  meet  milestones  and  represent  progress 
and  products  accurately  for  the  program’s  sponsor.  This  support  will  enable  your  sponsor  to  deliver 
on  obligations  successfully. 

In  order  to  conduct  your  program  at  NOSC,  your  program  must  fit  in  with  local  resources  and 
services;  this  includes  your  use  of  contractual  assistance. 

There  wiil  be  presentations  describing  most  of  the  NOSC  support  capabilities  available  during 
this  course.  The  purpose  of  this  section  is  to  describe  the  relationship  of  the  program  manager  to  other 
NOSC  organizational  groups  and  to  outside  organizations.  Organizational  details  are  subject  to  change, 
but  the  essentials  remain  valid. 
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‘Also  report  to  Line  Management  (Department  Heads) 


Figure  3.1.  1ED  and  technical  base  management  organization. 


The  role  of  the  program  manager  is  not  that  of  a  big  or  bigger  “wheel”  in  the  process,  but  rather 
a  combination  of  initiator,  catalyst,  counselor,  investigator,  and  reporter,  among  others.  Responsibility, 
like  virtue,  is  its  own  reward,  but  it  is  essential  in  RDT&E  programs.  A  prime  example  is  in  the  NASA 
space  shuttle  program,  where  “success  breeds  failure,”  just  as  it  does  in  large,  challenging,  successful 
Navy  programs.  We  are  tempted  to  take  each  further  extension  or  application  for  granted,  it  is  the 
responsibility  of  the  program  manager  to  examine  and  test  the  waters  before  taking  risks  and  venturing 
outside  of  the  planned  process  and  schedule,  even  though  there  are  demands  to  change  at  every  step. 

The  Navy,  as  part  of  DoD,  is  party  to  joint  program  developments  as  well  as  independent  efforts, 
so  oversight  by  higher  DoD  managers  has  resulted  in  the  adoption  of  24  initiatives  to  improve  the 
acquisition  process  (Table  3.1).  These  initiatives  recognize  potential  and  existent  frailties  in  our  RDT&E 
programs,  most  which  recur  and  must  receive  corrective  attention  or  prevention  through  constant 
awareness. 

During  the  various  stages  of  RDT&E,  external  influences  affect  decisions  and  progress.  Perhaps 
the  ultimate  influence  is  competition  for  limited  resources,  which  can  happen  at  any  stage  and  any 
organizational  level.  Priority  is  necessary  to  compete  successfully  for  resources.  Anticipation,  planning, 
and  negotiation  will  normally  avoid  confrontation.  Conflict  is  costly.  Paving  the  way  well  ahead  of 
program  needs  is  effort  well  spent. 

The  complexity  of  doing  RDT&E  business  increases  daily.  More  plans,  reports,  status-keeping, 
and  audits  are  to  be  expected.  Only  good  organization  and  procedures  maintained  throughout  the 
program  can  satisfy  the  demands,  while  freeing  the  productive  personnel  to  conduct  the  program. 

Team  development  is  a  t  important  topic  which  will  be  stressed  later  in  the  course.  The  essential 
requirements  for  development  toward  future  programs  can  be  stressed  here.  The  justification  for  this 
course  has  existed  for  many  years.  Program  managers  have  been  developed  in  all  the  different  ways 
up  to  now.  Some  came  with  industrial  experience,  some  with  academic  training,  and  most  have  developed 
through  cn-the-job  training  v/ith  a  mentor  at  some  stage  in  their  careers.  All  were  shaped  by  the  teams 
of  which  they  were  a  part. 

The  performance  of  a  project  team  must  be  reviewed  by  time  management  and  iheir  program 
progress  and  success  must  be  monitored  as  well.  Quality  assurance  in  individual  employee  performance 
is  the  objective  of  the  demonstration  program,  which  relies  upon  performance  toward  objectives,  with 
its  incentive  awards.  No  less  important  are  assessment  and  incentive  awards  for  program  teams  and 
managers  for  the  quality  of  their  performance  and  products  measured  against  system  performance  goals 
and  schedule  and  cost  targets. 

Every  citizen  has  the  right  to  expect  ethical  behavior  from  those  who  work  in  government.  The 
principles  are  clear,  and  corruption  is  widely  reported  and  punished.  Ethics,  however,  are  applied  in 
the  subtle  everyday  actions  and  relationships  within  your  team.  Fairness  and  compliance  are  perhaps 
useful  watchwords. 

Being  overly  accommodating  can  be  ruinous.  Security  breaches  are  often  traced  to  accommodation: 
too  little  time  to  check  the  area,  to  check  the  lock,  to  log  documents,  or  to  safeguard  the  information 
from  unauthorized  disclosures.  Overly  accommodating  poor  performance  by  members  places  a  weak 
link  in  your  chain  and  undue  burdens  on  other  team  members— who  notice  and  respond.  Accommodating 
imposed  changes  in  schedule  or  system  details— without  assessing  impact  downstream  on  other 
obligations— can  wreck  the  best  program  through  loss  of  performance,  credibility,  sponsorship,  and 
future  opportunity. 

The  references  offered  here  are  doctrinal  and  procedural.  The  essence  of  how  to  do  program 
management,  with  enjoyment,  comes  from  reading,  discussing,  and  experiencing  management  functions. 
I  hope  that  this  portion  of  this  course  makes  the  role  appear  attractive,  challenging,  and  rewarding. 


Table  3.1.  DoD  acquisition  improvement  program— the  Carlucci  Initiatives  (Kuhl  revision) 
Program  managers  shall .  .  . 

1.  Be  given  responsibility,  authority,  resources,  and  proper  requirements  and  funding  statements. 

2.  Be  given  authority  to  be  flexible  in  tailoring  acquisition  strategy. 

2.  Extend  responsibility,  authority,  and  accountability  to  the  lowest  effective  organizational  level. 

4.  Examine  low  and  high  risk  technologies  in  acquisition  strategy  development. 

5.  Consider  program  improvement  in  program  planning. 

6.  Pursue  economical  rates  of  production  within  constraints  as  a  basic  goal. 

7.  Consider  and  pursue  a  policy  of  standai  dization  whenever  and  wherever  beneficial. 

8.  Ensure  that  DON  personnel  take  a  businesslike  approach  with  industry  in  terms  of  motivation 
and  teamwork  goals. 

9.  Solicit  industry’s  comments  on  draft  PFPs  when  those  comments  are  likely  to  be  beneficial. 

10.  Inform  industry  accurately  regarding  the  funding  available  for  a  particular  program  and  not  mislead 
in  any  way. 

11.  Ensure  that  acquisition  strategies  ascribe  value  to  a  viable  industrial  base. 

12.  Procure  data  only  when  needed  and  if  it  is  sufficient  for  life-cycie  maintenance. 

13.  Provide  effective  estimates  of  resources  and  see  that  they  are  used  throughout. 

14.  Use  realistic  estimates  for  program  budgets  and  schedule  profiles. 

15.  Minimize  Lotal  life-cycle  costs  with  a  view  to  influence  acquisition  strategy. 

16.  Emphasize  value  engineering  when  participating  in  cost  saving  programs. 

17.  Consider  multiyear  procurement  in  all  applicable  situations. 

18.  Employ  independent  Navy  cost  analysis  in  contract  negotiations  whenever  possible. 

19.  Pursue  competition  vigorously  when  a  potential  benefit  exists. 

20.  Minimize  contract  changes;  but  once  changes  have  been  issued,  expedite  them. 

21.  Expedite  the  entire  acquisition  process  to  the  greatest  degree  possible. 

22.  Use  past  performance,  experience,  and  cost  realism  in  source  selection  and  cost  reimbursable 
contracting. 

23.  Emphasize  reliability,  maintainability,  and  producibility  from  initial  design  onward. 

24.  Insist  that  logistic  support  standards  will  not  be  compromised. 
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It  is  said  that  the  best  recipe  for  stress  avoidance  is 
Expect  changes 

Assist  others  to  expect  and  accommodate  changes 

Reward  yourself  for  things  you  do  well  and  try  to  make  that  your  style. 

As  Helen  Hayes  responded  to  an  interviewer: 

Success  is  how  others  assess  what  you  have  done; 
achievement  is  your  own  assessment. 

Figures  3.2  through  3.6  present  general  information  for  program  management  and  cover  such  things 
as  the  needs  document;  the  planning,  programming,  and  budgeting  system  (PPBS)  events;  and  the 
acquisition  process. 
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Figure  3.3.  Sequence  of  PPBS  events. 
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Figure  3.4.  Summary  overview  of  the  acquisition  process, 
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3.3  RESPONSIBILITIES  TOWARD  LINE  MANAGEMENT 


The  PM  must  be  responsible  toward  the  administrative  chain-of-command;  after  all,  that  is  where 
the  paycheck  comes  from.  The  line  management  is  responsible  for  administering  laws,  regulations, 
instructions,  directives,  internal/management  controls,  budgetary  directions,  and  a  host  of  initiatives 
“to  improve  management,  to  streamline  acquisition  procedures,  and  to  avoid  fraud,  waste,  and  abuse.” 

The  line  management  is  responsible  for  the  management  of  the  Center’s  resources.  The  PM  is 
dependent  upon  the  support  and  commitment  of  line  management  to  obtain  the  personnel,  facilities, 
and  administrative  support  which  are  essential  to  the  success  of  the  project.  The  first  formal  commitment 
of  line  management  is  the  laboratory  program  summary  (LPS)  with  DD1498.  An  approved  LPS  is 
required  to  accept  sponsor  funding  in  all  but  a  few  minor  cases;  therefore,  it  behooves  the  prospective 
PM  to  keep  the  administrative  chain-of-command  informed  of  prospective  taskings  and  the  associated 
project  planning.  Seldom  does  a  single  branch,  division,  or  department  have  all  of  the  resources  necessary 
to  support  a  project;  therefore,  the  support  of  other  organizations  within  the  Center  must  be  obtained. 
For  small,  short-term  involvements,  other  code  assistance  can  be  arranged  informally.  However,  long¬ 
term  relationships  between  codes  should  be  formally  established  by  an  internal  work  agreement  (IWA) 
or  memorandum  of  understanding  (MOU).  An  IWA  or  MOU  commits  line  mangement  in  both 
administrative  chains-of-command  to  achieve  certain  project  goals  within  a  given  schedule  for  an  agreed- 
to  level  of  funding;  it  may  establish  permanent  points  of  contact  in  each  organization  and  define  special 
working  relationships  for  the  assigned  tasks. 


Once  the  line  management  of  the  Center  is  committed  to  support  a  task,  the  PM  is  responsible 
for  carrying  out  the  management  responsibilities  of  the  Center  as  they  apply  to  that  project.  These 
responsibilities  include  the  proper  administration  of  funding,  the  adherence  to  proper  procedures  for 
procurements,  physical  security,  ADP  security,  CMS  security,  document  control,  and  plant  property 
management,  and  supporting  management  constraints  for  carryover  funding  and  management-to-payroll 
guidelines.  Since  some  of  these  responsibilities  may  conflict  with  the  most  efficient  accomplishment 
of  the  project,  it  is  imperative  for  the  PM  to  keep  line  management  informed  and  to  anticipate  potential 
impacts  of  management  edicts — often  exceptions  can  be  obtained  when  specific  problems  are  created 
by  new  rules,  or  line  management  can  assist  in  mitigating  the  impact  on  the  project. 

Beyond  these  explicit  responsibilities,  the  PM  must  be  ethical.  The  Standards  of  Conduct  (Ethics 
in  Government  Act  of  1978)  require  “avoiding  action  resulting  in,  or  creating  the  appearance  of 

—Using  government  position  for  private  gain 

—Giving  preferential  treatment  to  persons  or  organizations 

— Impeding  government  efficiency  or  economy 

—Losing  complete  independence  or  impartiality 

— Making  a  government  decision  outside  official  channels 

—Adversely  affecting  public  confidence  in  government  integrity.” 

The  PM,  as  the  leader  of  the  project  participants,  should  be  a  pillar  of  personal  honesty  and  integrity. 


3.4  RESPONSIBILITIES  TOWARD  THE  PROGRAM  CHAIN-OF-COMMAND 


1 


The  PM  exists  to  satisfy  the  specific  requirements  that  justify  the  establishment  of  the 
program/project.  These  requirements  flow  down  through  the  chain-of-command  that  is  responsible 
for  the  funding  allocated  to  address  the  requirement.  Not  surprisingly,  the  concerns  of  the  project  chain- 
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of-command  include  funding/budget  issues,  schedules/milestones,  project  progress  toward  satisfying 
the  stated  requirements,  support  system  requirements,  and  project  politics.  Changing  technology,  “bells 
and  whistles,”  and  changes  to  requirements  are  real  issues  of  interest  to  the  project  chain-of-command 
because  (1)  there  may  be  a  true  impact  on  the  project  or  (2)  each  individual  in  the  chain  must  fulfill 
the  need  to  contribute  to  the  project.  The  PM  must  be  aware  of  these  influences  in  order  to  communicate 
effectively  with  this  chain-of-command.  Another  perspective  to  keep  is  that  each  member  of  the  project 
chain-of-command  is  a  member  of  an  organization  with  its  own  distinct  administrative  chain-of-command 
with  similar  generic  organizational  concerns  as  NOSC.  However,  organizational  edicts  will  reflect  the 
needs  and  personality  of  the  organization;  therefore,  a  project  edict  may  conflict  with  Center  policy. 
Also,  a  project  chain-of-command  may  overlap  over  a  dozen  administrative  chains-of-command,  so 
the  potential  for  conflict  is  great.  The  successful  PM  gets  “in  tune”  with  each  organization  and  its 
idiosyncracies  and  applies  this  information  to  format  how  project  communications  take  place. 

The  greatest  need  of  the  project  chain-of-command  is  responsiveness.  As  in  successful  businesses 
where  “the  customer  is  always  right”  and  “service  is  our  most  important  business,”  these  attitudes 
are  important  in  the  PM  business  as  well.  Communications  in  response  to  the  project  chain-of-command 
must  be  accurate,  credible,  inexpensive,  timely,  and  professional.  Some  requests  may  seem  ridiculous — 
they  must  still  be  handled  responsively  and  responsibly.  The  immediate  acquisition  manager  (AM) 
sponsoring  the  project  depends  upon  the  good  advice  of  the  PM  and  the  project  team;  however,  the 
AM  also  needs  support  when  circumstances  direct  actions  that  the  PM  may  not  agree  with.  The  responsive 
PM  gains  the  respect  and  trust  of  the  project  chain-of-command  and  is  often  able  to  turn  poor  situations 
into  good.  Very  few  in  the  project  chain-of-command  can  help  the  project,  but  almost  everyone  can 
hinder  it.  Therefore,  the  effective  PM  keeps  the  needs  of  the  project  chain-of-command  satisfied. 


3.5  RESPONSIBILITIES  TOWARD  THE  PROJECT/PROGRAM  TEAM 

The  PM  is  a  project  manager  but  also  a  team  leader.  People  are  led;  materials,  funds,  and  schedules 
are  managed.  The  PM  must  communicate  to  the  project  team  the  goals  of  the  project,  instill  in  each 
participant  a  feeling  of  contribution  and  worthiness,  support  the  needs  of  each  team  member’s 
assignment,  monitor  team  progress,  anticipate  problems,  make  decisions  so  that  each  team  member 
has  clear  direction,  and  ensure  that  the  extraordinary  accomplishments  of  team  members  are  recognized. 
The  PM  must  delegate  responsiblities  and  authority  to  the  task  team  leaders  and  then  hold  them 
accountable  for  performance.  No  PM  can,  or  should,  do  everything  alone— it  must  be  accomplished 
through  people.  The  successful  PM  recognizes  this  fact  and  attempts  to  bring  out  the  best  in  each  team 
member. 

The  outstanding  PM  is  one  who  serves  as  a  model  of  commitment,  dedication,  and  moral  integrity 
for  everybody  on  the  project  team. 


3.6  THE  SUCCESS  PATTERN 

The  successful  PM  will  share  certain  characteristics  with  all  other  successful  PMs.  The  unsuccessful 
PM  will  lack  one  or  more  of  these  characteristics: 

a.  Knows  the  job— The  PM  knows  the  acquisition  system  and  the  chains-of-command  better 
than  most  of  the  people  running  their  individual  “fiefdoms.”  The  PM  knows  the  requirements 
better  than  anyone  else  in  the  project  chain-of-command.  The  PM  knows  where  to  go  for 
assistance,  for  advice,  for  expertise,  and  for  decisions  beyond  the  PM!s  authority.  The  PM 
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has  a  clear  and  complete  view  of  the  project  goals  (including  “should  be  done”  goals,  not 
merely  those  goals  explicitly  stated)  and  applies  this  knowledge  in  the  planning  and  decision¬ 
making  processes. 

b.  Takes  responsibility— The  PM  acts  as  the  ultimate  authority  for  the  project.  The  PM  is  willing 
to  assume  the  total  responsibility  for  the  project— often  this  provides  de facto  authority  because 
others  in  the  chain-of-command  are  relieved  to  not  have  to  make  tough  decisions. 

c.  Makes  decisions— The  PM  makes  decisions  on  time.  Often  projects  get  into  trouble  for  lack 
of  clear  direction.  Even  a  “bad”  decision  is  better  than  no  decision  if  it  clearly  defines  the 
immediate  tasks.  The  successful  PM  assesses  what  decisions  must  be  made  immediately  (and 
makes  them)  and  what  decisions  require  more/better  information  (and  tasks  the  team  to  develop 
the  required  information).  The  PM  is  not  afraid  to  admit  a  mistake  and  to  correct  a  decision 
when  it  is  clearly  wrong,  but  decisions  are  not  changed  easily— waffling  or  flip/flopping  is 
as  confusing  to  the  team  as  not  having  any  direction. 

d.  Conveys  strength  and  dedication  (stubbornness,  bull-headedness,  single-mindedness)— The  PM 
has  a  single-mindedness  toward  achieving  the  project  goals.  The  PM  is  willing  to  do  whatever 
is  necessary  to  accomplish  these  ends,  except  that  he/she  is  also  a  pillar  of  ethical  behavior. 
When  “the  system”  puts  a  roadblock  in  the  way,  the  PM  investigates  alternatives  “over,  around, 
under,  or  through.”  A  major  manifestation  of  this  dedication  is  in  the  responsiveness  to  the 
chain-of-command . 

e.  Communicates  “infectiously”— The  PM  must  be  an  effective  communicator.  Briefing  skills 
are  particularly  important.  The  PM  rarely  has  the  true  authority  needed  to  do  the  job,  so 
the  ability  to  convince  others  of  the  rightness  of  a  decision  becomes  essential.  Communication 
is  a  major  key  to  success  with  the  chains-of-command.  Communicating  “infectiously,”  the 
PM  instills  excitement,  fervor,  and  commitment  in  the  audience  and  brings  people  onboard 
the  project  bandwagon.  The  same  principles  apply  in  the  PM’s  task  of  leading  the  project  team. 

f.  Leads— The  PM  must  lead  the  project  team.  The  PM’s  leadership  abilities  often  are  essential 
to  establishing  the  team  concept  among  the  otherwise  diverse  project  participants.  Through 
leadership,  the  project  participants  are  also  inspired  to  the  dedication  and  commitment  to 
the  project  that  the  PM  exhibits.  “It  is  no  trick  to  get  outstanding  people  to  do  an  effective 
job.  It  takes  an  effective  leader  to  take  average  people  and  get  them  to  do  an  outstanding  job.” 

g.  Delegates— Although  the  ultimate  project  authority,  the  PM  delegates  responsibility  with 
authority  to  the  project  task  leaders.  The  task  leaders  participate  in  the  planning  process  (as 
much  as  possible),  accept  the  assigned  responsibilities,  and  are  held  accountable  to  the  tasked 
performance  standards.  Task  leaders  are  encouraged  to  redelegate  within  their  own  task 
structure.  The  PM  never  considers  himself /herself  any  less  responsible:  a  mistake  by  a  team 
member  reflects  directly  on  the  PM,  but  the  PM  also  trusts  the  team  members  to  act  responsibly 
and  to  the  best  interest  of  the  project.  Errors  are  quickly  detected  and  corrected  by  the  program 
controls/project  team  structure.  Nobody  is  expected  to  be  perfect,  but  everyone  is  held  to 
his/her  best  effort.  Typical  successful  projects  are  executed  by  small,  dedicated  teams.  The  small 
team  size  promotes  the  effectiveness  of  the  PM’s  personal  leadership  influence  and  the  ability 
to  hold  each  team  member  accountable  to  the  tasks. 


3.7  PROGRAM/PROJECT  CHARTER 


A  program  or  project  charter  formalizes  the  objectives  and  obligations  of  the  PM.  Ideally,  the 
charter  is  established  in  writing  from  both  the  sponsoring  acquisition  manager  and  the  PM’s  department 
head.  In  practice,  some  charter  elements  are  documented  in  the  statement  of  work  accompanying  the 
tasking,  and  other  elements  are  established  in  the  PM’s  goals  and  objectives.  It  behooves  the  PM  to 
ensure  that  these  individual  directions  do  not  conflict;  this  is  most  easily  accomplished  by  keeping  the 
administrative  chain-of-command  aware  of  the  potential  task  statements.  The  following  are  the  minimum 
elements  of  a  true  PM  charter: 

•  Objective  System  Description— a  brief  statement  of  the  requirements  the  project  is  responding  to 

•  Project  Scope— the  start,  finish,  and  resource  constraints 

•  Authorities 

•  Limitations  of  Authorities 

•  Responsibilites 

•  Relationship  to  the  Sponsoring  Authority— reporting  requirements,  task  expectations  beyond 
mere  project  execution 

•  Special  Operation  Relationships  (who  does  what  to  whom) 

a.  Activities  higher  in  the  project  chain-of-command 

b.  Activities  outside  the  Navy 

c.  Other  field/support  activities 

•  Staffing  and  Organization 

•  Project  Transition  or  Disestablishment 
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SECTION  4 

PROPOSAL  DEVELOPMENT  AND  MARKETING 


4.1  INTRODUCTION 


4.1.1  General 

The  purpose  of  this  section  is  to  provide  information  that  wili  facilitate  marketing  and  the 
preparation  of  proposals.  As  can  be  noted  from  the  contents,  marketing  in  all  categories  from  6. 1 
through  6.6  and  nonprogram  6  RDT&E  is  covered  as  well  as  joint  service  and/or  foreign  RDT&E. 
Some  “road  maps”  as  well  as  other  guidelines  are  also  included. 

4.1.1  References 

The  references  listed  below  were  used  in  the  preparation  of  this  section.  Copies  are  held  by  the 
NOSC  R&D  Planning  Guidance  Group.  Feedback  from  Program  Managers  and  students  who  have 
taken  the  NOSC  Program  Managers  Course  has  also  been  included. 

DoD  Directive  5000. 1 ,  Major  System  Acquisitions 

DoD  Instruction  5000.2,  Major  System  Acquisition  Procedures 

DoD/GAO  Programming  and  Budgeting  System 

Navy  Program  Manager’s  Guide,  1985  Edition 

NOSC  Program  Managers  Handbook,  July  1986 

Navy  Programming  Manual 

OPNAVINST  5000.42C,  Research,  Development,  and  Acquisition  Procedures 
RDT&E/Acquisition  Management  Guide,  10th  Edition 

Technical  Marketing  and  Proposal  Preparation  Course  by  Hyman  Silver,  Oct  1986 


4.2  MARKETING 


4.2.1  Definitions 
Marketing 

is  the  analyzing,  planning,  and  controlling  of  organizational  resources,  policies,  and  activities 
with  a  view  to  satisfying  the  needs  and  wants  of  current  and  potential  Center  sponsors  and/or 
customers. 


Informal  Marketing 

is  any  verbal  commitment,  inquiry,  or  offer  to  perform  work  for  a  sponsor  or  customer,  with 
the  objective  that  such  discussion  will  lead  to  a  proposal  submission  requiring  formal  acceptance 
by  both  the  initiating  activity  and  the  sponsoring  and/or  customer  activity. 

4.2.2  Marketing  Objective 

The  prime  objective  of  marketing  is  to  understand  what  the  Navy  might  need  and  to  obtain  work 
within  the  NOSC  mission  that  enhances  and  strengthens  the  Navy,  Marine  Corps,  joint  service,  or 
other  DoD/government  agencies’  ability  to  perform  their  mission. 

4.2.3  Marketing  Principles 

Development  of  marketing  principles  at  the  Center  is  closely  related  to  sponsor  interface.  This 
direct  interface  provides  a  ready  means  for  NOSC  program  and  project  management  to  explore  new 
ideas  and  concepts  with  sponsors  directly  responsible  for  development  and  funding  support  of  NOSC 
mission-oriented  programs.  Much  of  the  Center’s  support  is  obtained  through  direct  sponsor  interface 
and  often  new  work  requests  result  as  a  natural  follow-on  to  existing  efforts.  Effective  dialogue  with 
sponsors  is  a  prerequisite.  Personal  contact  is  considered  the  most  effective  way  of  enhancing  and  selling 
the  technical,  scientific,  and  managerial  expertise  of  the  Center. 

4.2.4  General  Guidelines  for  Marketing 

The  following  should  be  considered  in  support  of  effective  marketing: 

a.  Ensure  that  work  is  in  response  to  a  valid  Navy  need.  If  no  formal  need  exists,  draft  a 
requirement  to  assist  the  sponsor  in  the  approval  process.  For  a  Technology  Base  program, 
review  the  ONT  Mission  Area  Strategies  and  pertinent  approved  Block  Plans.  For  Advanced 
or  Engineering  Development,  review  pertinent  Naval  Plans,  Warfare  Appraisals,  TORs,  ORs, 
or  JMSNS.  Copies  may  be  obtained  from  the  Navy  Acquisition  R&D  Information  Center 
(NARDIC),  NOSC,  1023  E.  Green  Street,  Pasadena,  CA,  Tel:  (213)  792-2452  or  NAVSEA-2452. 

b.  Review  NOSC  TD  799,  entitled  Windows  of  Opportunity for  Naval  Systems;  update  with  current 
plans  and  program  schedules  relevant  to  your  product  line.  Identify  target  platform/system 
windows  and  estimate  force  level  and  inventory  needs.  Construct  estimates  of  funds  available 
and  look  for  “windows  of  opportunity”  as  funding  requirements  fall  and  open  “windows” 
in  your  product  area. 

c.  Ensure  there  is  no  obvious  duplication  or  redundant  effort.  (Query  the  DTIC  data  bank  and 
check  the  NOSC  Technical  Library.)  Identify  related  work  and  determine  if  there  is  any 
duplication  of  effort.  Identify  sponsors  and  others  involved. 

d.  Identify,  describe,  and  characterize  the  immediate  customer(s),  both  the  organizations  and 
the  individuals  who  represent  them.  Develop  a  survey  of  requirements  and  views  through 
interviews  and  examination  of  publications.  (See  the  “Organizational  Chart  Service,”  Defense 
Marketing  Service  publications,  and  DoD  “yellow  pages”  available  through  the  NOSC  R&D 
Planning  Guidance  Group.) 

e.  Identify  Fleet,  shore,  and  Marine  Corps  units  that  provide  the  best  opportunity  for  obtaining 


information  and  understanding  of  the  users’  needs  and  problems.  Discuss  your  approach  with 
local  liaison  offices  and  technical  officers  assigned  to  NOSC. 

f.  Develop  a  comprehensive  description  of  NOSC’s  market,  including  potential  as  well  as  immediate 
customers.  Know  the  “competition”  and  the  relative  strengths  and  limitations  of  their  concepts 
as  well  as  yours.  (To  get  an  objective  e"aluation  of  the  competition,  a  systems  analysis  may 
be  necessary.) 

g.  Ensure  that  marketing  efforts  are  synchronized  in  time  to  support  the  RDT&E  planning, 
programming,  and  budgeting  cycles.  (Refer  to  NOSC  TD  1 189  entitled  NOSC  Planning  Calendar 
and  NOSC  briefing  material  entitled  “How  the  Puzzle-Palace  Works.”) 

h.  Participate  in  related  IR&D  reviews  to  ensure  awareness  of  related  R&D  and  potential  sources 
of  contract  support. 

i.  Plan  and  prepare  program  proposals  in  consonance  with  the  Navy/DoD  planning,  programming, 
and  budgeting  cycle,  and  provide  effective  support  to  sponsors  in  obtaining  funds  for  the 
programs. 

j.  If  the  program  has  joint-service  potential,  expand  above  efforts  to  appropriate  users. 

k.  If  the  area  involves  Research  (6.1)  or  Exploratatory  Development  (6.2),  seek  advice  from  the 
NOSC  Technology  Base  Block  Plan  Managers. 

l.  For  programs  involving  intelligence  or  other  sensitive  work,  contact  the  NOSC  Intelligence 
Office. 

m.  For  general  assistance,  contact  the  NOSC  R&D  Planning  Guidance  Group. 

n.  Additional  guidelines  and  instructions  for  conducting  marketing  by  initiating  proposals  are 
included  here. 

4.2.5  Selling  Capabilities 

Make  the  product  and  capabilities  known.  Take  every  opportunity  to  provide  visibility  for  NOSC 
resources  and  capabilities.  Be  prepared  to  provide  briefings,  both  internal  and  external.  Make 
presentations  at  related  symposiums  and  publish  papers.  “Advertise”  current  accomplishments  in  the 
NOSC  “Technical  Briefs”;  this  publication  is  distributed  widely  to  sponsors.  Join  and  become  an  active 
member  of  related  societies/associations.  Incorporate  proposed  programs  in  documents  such  as  those 
listed  in  Table  4. 1 . 

Table  4.1.  List  of  key  documents  in  which  proposed  programs  could  be  discussed  or  in  which  the 
“requirement”  could  be  established. 

Fleet  R&D  Objectives/Deficiency  Reports 
Pertinent  master  plan 

Pertint  t  SYSCOM’s  Sponsor  Proposed  Program  (SPP) 

Pertinent  OPNAV  Resource  Sponsor’s  Issue  Papers 
Pertinent  OPNAV  Warfare  Appraisal 
TORs,  DOPs,  and  ORs 
Mission  Areas  Strategies  (6.2) 

Key  Naval  Needs  (6.1) 


4.2.6  Finding  a  Sponsor 

Be  prepared.  Review  and  study  the  appropriate  referenced  documents  that  impact  or  are  issued 
by  that  sponsor.  There  are  many  helpful  documents  in  the  areas  of  planning,  guidance,  Navy  deficiencies, 
budget,  and  the  RLT&E  process  itself.  In  addition  to  the  documents  listed  under  the  References  of 
the  INTRODUCTION,  Table  4.2  lists  some  additional  major  planning/needs/requirements  documents 
that  are  available.  Study  the  basic  documents  that  relate  to  the  area  of  interest.  Keep  in  mind  the  following 
questions.  What  does  the  Navy  need?  Where  is  the  threat  going?  How  much  money  is  flowing?  Who 
is  buying?  Selling?  Understand  which  documents  apply  and  the  need  of  the  sponsor  or  prospective 
sponsor.  Market  expertise  will  solve  problems.  Build  credibility  as  an  expert  by  using  the  language 
of  the  disciplne  under  consideration  and  portray  an  awareness  and  understanding  of  the  sponsor’s 
problems. 


Table  4.2.  Major  Planning  Documents. 


5000.1/5000.2/5000.3/5000.42C  series  of  instruct'^ns 

Annual  Posture  Statements  by  SECDEF,  SECNA  ’  CJCS,  ASN(RE&S);  USDR&E,  CNO,  OP-098,  etc. 

ASW  Master  Plan 

Attack  Submarine  Warfare  Plan 

Avionics  Master  Plan 

“CIRCA  2000”  (N1SC  Long-Range  Threat  Document) 

CNO’s  Goals  and  Objectives 
CNO  Long-Range  Planning  Conference  Proceedings 
CNO  Program  Assessment  Memorandum  (CPAM)  on 
—Maritime  Strategy 


-RDA 
—Total  Force 
Defense  Guidance 

Department  of  the  Navy  Program  Planning  Guidance  (DNPPG) 
DIPP  (Defense  Intelligence  Publication  for  Planning) 

Extended  Planning  Annex 
EW  Master  Plan 

Joint  Intelligence  Estimates  for  Planning  (J1EP) 

Joint  Strategic  Planning  Document  (JSPD)-especially  Annex  D 
Key  Naval  Needs  (promulgated  by  ONR) 

Maritime  Strategy 

Master  Plan  for  Embedded  Computers 
Mission  Area  Strategies 
Naval  Aviation  Plan 
Naval  C2  Plan 

Navy  Study  Plan  (DONSTAPA) 

National  Intelligence  Estimate  (N1E)  11-15 
NORAD  Master  Plan  (USAF) 

POM  Serials  (published  by  OP-90i) 

RDDOs  from  CINCs  (also  see  SiTREP  messages) 

Space  Master  Plan 

Special  Warfare  Master  Plan 

Sponsor  Program  Proposals  (SPPs) 

Surface  Warfare  Plan 

Tech  Base  Planning  Guidance  &  TTPG 

Top-Level  Warfare  Requirements  (TLWRs) 

USMC  C2  Master  Plan 
LSMC  Midrange  Objectives  Plan 
Warfare  Aporaisal/CPAMs: 

-Amphib/SPAWAR 
— AAW 
-ASW 
—Chemical 
— F.W 

—Maritime  Strategy  CPAM 
;  —Mine 
-RDA  CPAM 


—Space 
—Strategic 
— Strike/ASWU 
—Summary 
—Tactical  C3 
—Tactical  Nuclear 
—Total  Force  CPAM 
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(The  NOSC  R&D  Planning  Guidance  Group  has  most  of  the  documents  listed  in  Table  4.2.) 

In  many  cases,  it  may  be  necessary  to  apply  an  existing  solution  to  a  problem.  Be  on  the  lookout 
for  sponsors.  Take  advantage  of  Fleet,  Lab,  and  even  industry  conferences  where  the  sponsors  are 
speakers.  Use  opportunities  at  conferences  to  question  key  players.  Also,  refer  to  the  conference  when 
asking  for  appointments  in  the  future. 

When  meeting  a  prospective  sponsor  consider  the  following  concerns: 

The  sponsors  don’t  know 
— who  you  are 
—your  organization 
—your  product  area/line 
—what  your  organization  stands  for 
— your  organization’s  customers 
— your  organization’s  record  and  reputation 

In  meeting  a  prospective  sponsor,  first  sell  yourself,  then  ideas,  and  finally  our  organizational 
resources. 


4.2.7  Market  Research 

NOSC  TD  799,  entitled  Windows  of  Opportunity  for  Naval  Systems  (U),  SECRET,  illustrates  one 
method  for  discovering  opportunities.  (Remember  that  in  order  to  reach  an  initial  operational  capability 
(IOC)  date.  R&D  may  have  to  start  up  to  14  years  beforehand!)  Figure  4. 1  shows  windows  of  opportunity 
as  related  to  IOC  dates  for  various  representative  systems.  Examine  the  systems  by  answering  the 
following  questions:  What  systems  are  currently  in  the  Fleet?  When  were  the  systems  purchased?  When 
will  they  wear  out?  What  happened  with  past  systems?  What  is  the  status  of  current  systems?  What 
systems  are  being  considered  for  the  future?  Have  I  missed  the  window?  Should  I  focus  on  a  midlife 
upgrade  or  a  new  start? 

Another  method  for  predicting  a  possible  opportunity  involves  “affordability  forecasting”  (Figure 
4.2).  In  this  approach,  examine  an  area  of  interest  under  the  control  of  a  sponsor  from  the  perspective 
of  funding  history  and  market  share.  In  other  words,  determine  how  much  funding  is  available  and 
when  the  funds  become  available,  then  attempt  to  target  the  time  of  optimum  cash  flow  in  the  area 
of  interest. 

4.2.8  Market  Research  via  Interviews 

The  best  way.  to  find  out  what  will  be  needed  and  when  the  “windows  of  opportunity”  will  open 
is  by  direct  interviews.  (These  should  not  be  mixed  with  selling  because  the  sponsor  may  not  respond 
favorably  later.) 

a.  Have  an  “objective”  market  analyst  conduct  the  interview.  (The  interview  is  done  for 
information,  not  sales,  so  listen  to  what  the  sponsor  actually  says,  not  what  you  want  to  hear.) 
Find  out  what  this  prospective  sponsor  thinks. 

b.  If  you  are  operating  as  your  own  market  analyst,  call  the  prospective  sponsor  personally.  (Ask 
the  sponsor  for  his/her  views  on  the  future  for  the  area  of  interest.) 

c.  Do  your  homework.  Read  the  publications  authored  by  that  office  or  which  impact  that  office; 
prepare  questions  and  issues  based  on  that  information. 
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d.  Make  sure  proper  clearances  are  forwarded. 

e.  Compile  a  questionnaire  ahead  of  time.  Establish  priorities  among  the  questions  in  case  the 
interview  time  is  cut  short.  Start  with  simple  yes/no  questions  and  then  move  into  the  open- 
ended  inquiries.  The  sequence  of  questions  should  reflect  a  logical  flow,  a  smooth  transition 
from  topic  to  topic.  Once  the  questionnaire  is  prepared,  conduct  a  dry  run.  Do  not  take  a 
tape  recorder  to  the  interview.  The  sponsor  will  talk  more  freely  if  not  recorded.  If  certain 
specific  information  is  to  be  retained  during  the  interview,  take  notes.  (Later,  after  the  interview 
is  over,  impressions  may  be  taped  so  they  are  not  lost.) 

f.  Develop  and  use  interviewing  skills.  Ensure  that  the  prospective  sponsor  is  doing  90  percent 
of  the  talking.  Conduct  the  interview  in  the  sponsor’s  office  (home  territory).  Sometimes  it 
helps  to  loosen  up  a  sponsor  by  showing  a  hard  copy  of  a  viewgraph  that  reflects  your 
interpretation  or  summary  of  their  publications,  related  plans,  issues,  etc.  (This  is  one  way 
to  indicate  preparedness  and  familiarity  with  the  situation.)  Establish  the  prospective  sponsor 
as  the  expert.  Remember  that  lunches  are  good  for  establishing  rapport  but  are  not  the  place 
for  hard  data  or  classified  ideas.  Finally,  ask  what  other  people  you  should  see  and  what  other 
material  should  be  read.  Leave  the  prospective  sponsor  something  like  a  data  plot,  photographs, 
charts,  etc.,  and  attach  your  business  card. 


4.2.9  Winning/New  Marketing  Strategies 

After  gathering  insight  into  the  marketplace,  develop  a  market  strategy.  Marketing  strategies  should 
consider  the  following  items: 

a.  Identify  “targets”  early.  When  the  customer  is  contacted  for  a  proposal  following  the  marketing 
survey,  communicate  in  the  customer’s  language  and  to  the  customer’s  biases. 

b.  Select  targets  that  match  strengths;  limit  the  number  of  targets  to  be  pursued  at  any  one  time. 

c.  Identify  weaknesses  in  abilities  to  compete  and  start  correcting  them  by  training,  hiring,  and 
teaming.  Increase  contact  with  Fleet  users  and  competitors. 
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Know  the  customer’s  requirements/goals;  read  studies  and  Fleet  operational  reports  related 
to  the  product  area. 


e.  Determine  if  the  customer  considers  you  a  “front  runner”(i.e.,  in  the  top  three  contenders); 
if  not,  ask  how  to  build  up  confidence  for  future  proposals. 

f.  Obtain  management’s  commitment  and  commit  resources  to  staff  a  good  proposal  team.  Give 
the  team  sufficient  time  and  resources  (should  be  proportional  to  the  size  of  the  project). 


g.  Help  document  the  operational  need.  Submit  requirement  via  CINCs  (work  through  your  local 
NSAP  office). 


h.  Consider  showcasing  the  proposed  system  in  war  games. 


i.  Participate  in  high-level  studies,  appraisals,  strategies,  master  plans,  etc.,  or  cultivate  those 
who  do  so  to  influence  their  recommendations  to  improve  visibility. 


j.  Support  the  sponsor  (establish  an  NSTEP  assignment— establish  an  “agent  in  place”). 

k.  Offer  to  bail  out  troubled  programs  and  your  competition. 


1.  Support  the  emerging  Weapons  Systems  Architecture/Weapons  Systems  Engineering 
(WSA/WSE)  process. 
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4.3  UNDERSTANDING  THE  RDT&E  PROCESS 


In  order  to  effectively  market,  it  is  necessary  to  have  a  basic  understanding  of  the  procedures  used 
for  planning,  programming,  and  budgeting  as  they  pertain  to  the  Technology  Base,  Advanced 
Development,  and  Engineering  Development  programs. 

4.3.1  The  Planning,  Programming,  and  Budgeting  System 

The  Planning,  Programming,  and  Budgeting  System  (PPBS)  is  a  system  that  supports  the  DoD 
decision-making  process.  The  Department  of  the  Navy’s  RDT&E  Management  Guide  contains 
information  on  the  PPBS.  Figure  4.3  is  included  to  provide  a  simple  overview  of  the  PPBS  process. 

4.3.2  The  Program  Objectives  Memorandum  (POM) 

The  POM  is  the  document  by  which  the  Navy  describes  and  proposes  its  total  program  to  OSD. 
It  includes  all  Navy  programs  and  force-level  objectives  and  presents  8  years  of  budget  information. 

4.3.3  The  2-Year  POM  Cycle 

Under  the  new  2-year  POM  cycle  (Figure  4.4),  the  POM  is  prepared  every  other  year,  which  is 
referred  to  as  the  “on-year.”  During  an  “on-year,”  the  cycle  commences  during  early  November  and 
ends  with  the  POM  submission  to  SECDEF  in  May  of  the  following  year. 

The  first  year  of  the  2-year  POM  development  cycle  is  called  the  “off-year.”  It  focuses  on  appraisals 
and  on  the  “State  of  the  Navy.”  The  appraisal  process,  which  consists  of  a  series  of  appraisals,  extends 
over  a  6-month  period  as  shown  in  Figure  4.4.  These  appraisals  provide  the  opportunity  for  identification 
and  analysis  of  emergent  major  issues.  Commencing  in  May  of  the  POM  development  off-year,  the 
DON  Program  Strategy  Board  (DPSB)  reviews  proposals  for  adjustments  to  a  single  midyear  Five  Year 
Defense  Program  (FYDP)  update.  The  DON  Consolidated  Planning  and  Programming  Guidance 
(DNCPPG)  is  the  product  of  the  appraisal  and  DPSBD  processes  and  becomes  the  foundation  for 
the  second  year  of  the  POM  development  cycle  (the  “on-year”). 

Actions  during  the  on-year  will  focus  on  resolution  of  previously  identified  issues  and  earlier  POM 
development  by  the  OPNAV  resource  sponsors.  Final  development  of  the  POM  will  commence  upon 
issuance  of  the  DNPPG  during  early  November. 

4.3.4  Phases  of  POM  Development 

The  three  phases  of  POM  development  and  their  timeframes  are 
Program  Planning  —  (5  months) 

Programming  —  (5  months) 

Final  POM  Development  —  (3  months) 
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"  BAM  —  Baseline  Awum*»i  Memorandum  ' 
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ORB  —  Defense  Rewirm  Board 
IPI.  —  Integrated  Priorit>  lists 

‘  ISR  —  Invest  meat  Strateg}  Reslew 
PBD  —  Pmt ram  Budget  Decision 
W  —  Pmpf  sed  Program  Change* 

SPP  —  Sponsor  Propram  Proposal* 
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4.3.5  Marketing  in  Synch  with  the  POM  Process 

Since  timing  is  very  important  in  proposing/getting  programs  into  the  POM,  the  POM-90  schedule 
is  included  (see  Appendix  4A).  As  can  be  seen  from  Figure  4.5  and  Appendix  4A,  the  POM  process 
is  lengthy.  As  the  process  progresses  and  programs  are  programmed,  it  becomes  more  difficult  to  market 
a  program  (see  Figure  4.5).  Therefore,  unless  the  proposed  program  is  urgently  needed  by  the  Navy, 
it  should  be  proposed  early  in  the  cycle.  (If  it  is  marketed  late  in  the  POM  process,  other  programs 
may  have  to  be  deleted  to  provide  funds,  thus  making  marketing  more  difficult.) 


Figure  4.5.  Development  of  POM-90  using  the  2-year  POM  development  cycle. 


4.4  THE  SYSTEM  ACQUISITION  PROCESS 

Figure  4.6  presents  a  simplified  overview  of  the  system  acquisition  process.  The  process  is  discussed 
in  terms  of  DoD’s  RDT&E  program  categories,  for  example,  Research  (6.1),  Exploratory  Development 
(6.2),  and  Advanced  Development  (6.3).  (NOTE:  Advanced  Developments  also  can  occur  under  non- 
RDT&E  accounts  such  as  Strategic  Warfare  (Program  1),  General  Purpose  Forces  (Program  2),  and 
C3I  (Program  3).  Category  6.3  also  includes  Advanced  Technology  Demonstrations  (6.3A).  Table  4.3 
summarizes  the  acquisition  categories  (ACATS)  and  related  information.  Figures  4.7  and  4.8  and  Tables 
4.4  and  4.5  show  the  organizations/offices/people  involved.  Finally,  Figure  4.9  illustrates  the  length 
and  involvement  of  the  process. 
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Table  4.3.  Definitions  and  responsibilities  for  acquisition  categories  (ACAT). 


Acquisition 

Categories 

Documentation 

(ACAT) 

Criteria 

Decision 

R  i  '  ements 

I 

Major  Programs: 

TOR 

SCP 

•  >200M  RDT&E 

SECDEF 

DOP 

DCP 

in  production 

*JMSNS 

and 

•  National  urgency 

•  As  directed 

TEMP 

II  S 

Less  than  Major  Programs: 

SECNAV 

TOR 

NDCP 

— 

•  >100M  RDT&E  or 

— 

DOP 

& 

II  c 

>200M  Prod 

CNO 

OR 

TEMP 

III 

•  Significant  impact  on 

DCNO/ 

TOR 

TEMP 

military  characteristics 

DMSO 

DOP 

OR 

IV  T 

•  All  other  acquisitions 

SYSCOM 

TOR 

TEMP  | 

•  OPEVAL  required 

COMMANDER 

DOP 

OR 

IV  M 

All  others 

SYSCOM 

TOR 

TEMP 

COMMANDER 

DOP 

OR 

TOR  —  Tentative  Operational  Requirement 

DOP  —  Development  Options  Paper 

JMSNS  —  Justification  of  Major  Systems  New  Start 

OR  —  Operational  Requirement 

DCP  —  Decision  Coordination  Paper 

SCP  —  System  Concept  Paper 

NDCP  —  Navy  Decision  Coord;nation  Paper 

TEMP  —  Test  and  Evaluation  Master  Plan 

*The  JMSNS  starts  as  an  OR  within  the  Navy  and  ACAT  I  status  and  other  endorsement  by  JCS. 
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Table  4.4. 


Resource  sponsors  and  tasks. 


PLATFORM  SPONSORS 


> 


I 

I 


Aviation . OP-05 

Submarine . OP-02 

Surface . OP-03 


SUPPORT  SPONSORS 


C3 . OP-094 

Command/Administration . OP-098 

Intelligence . OP-009 

Logistics . OP-04 

Manpower,  Personnel,  Training . OP-01 

Medical . OP-093 

Military  Assistance . OP-08 

Plans,  Policy,  Operations . OP-06 

Underseas  Surveillance/Oceanography . OP-095 


TASKS  OF  PLATFORM  AND  SUPPORT  SPONSORS 

•  Develop  programs 

•  Participate  in  appraisals/CPAMs 

•  Initiate  the  OR 


Table  4,5.  Summary  of  claimants’  responsibilities. 

•  Have  primary  responsibility  for  program  execution. 

•  Submit  suggested  programs  to  sponsors  (SYSCOMS  provide 
pricing  information). 

•  Review  and  comment  on  proposed  programs. 
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4.5  RESEARCH  (primarily  Navy  6.1) 


The  Chief  of  Naval  Research  (CNR)  (Figure  4.10)  is  responsible  for  Navy  Research  (6.1)  which 
includes  the  preparation  and  submission  of  inputs  to  the  POM  process.  CNR  is  provided  major  assistance 
by  the  Office  of  Naval  Research  (ONR).  Money  appropriated  for  Research  is  distributed  by  CNR  to 
the  Claimants.  ONR  is  the  Principal  Claimant.  Other  Claimants  include  NRL,  NORDA,  the  NPGS, 
NMRCD,  and  a  few  other  activities  with  very  minor  research  programs.  (The  SYSCOMs  no  longer 
receive  Navy  6.1  money,  i.e.,  they  are  not  a  6.1  Claimant.) 


4.5.1  Sources  of  6.1  Funding  and  Marketing  of  6.1 

a.  CNR  6.1  Funding 

About  half  of  NOSC’s  6.1  funds  are  received  from  CNR  via  the  Technical  Director  of  ONR.  These 
funds  are  for  the  Independent  Research  (IR)  Program.  The  amount  is  determined  by  the  Technical 
Director  of  ONR  following  review  of  previous  IR  programs.  However,  the  detailed  project  structure 
of  the  IR  Program  is  determined  indirectly  by  NOSC.  IR  is  “independent”  of  Washington  control. 
Each  year  the  Technical  Director  of  NOSC  issues  a  call  (about  March/April)  for  proposals  from  the 
NOSC  technical  community  to  do  high-risk  research.  Written  preproposals  are  reviewed  by  the  Program 
Director  for  Research  who  decides  which  proposals  will  be  made  orally  to  a  group  of  peers  selected 
specifically  for  each  meeting  These  proposals  are  evaluated  and  the  resulting  recommendations  are 
sent  to  the  Technical  Director.  The  aggregate  of  projects  selected  by  the  Technical  Director  constitutes 
the  NOSC  Independent  Research  Program. 

b.  Funding  from  ONR  Code  1 1 

NOSC  also  receives  6.1  money  (PE61 153N)  from  ONR  Code  1 1  as  a  result  of  proposals.  It  is  with 
this  type  of  funding  that  NOSC  strives  to  transition  high-risk  IR  work  into  exploratory  development. 
Proposals  are  encouraged  in  this  area  from  NOSC  technical  personnel  performing  IR  work.  Individuals 
are  encouraged  to  discuss  their  potential  proposals  with  the  NOSC  Program  Director  for  Research 
and  to  prepare  such  proposals.  The  ideal  time  to  submit  proposals  is  in  the  spring,  prior  to  start-up 
of  the  next  fiscal  year. 


SPAWAR 
LAB  FUNDING 


Contract  Research  Program  (CRP) 
Applied  Research  Program  (ARP) 


Figure  4.10.  The  organization  for  research  (6.1). 


c.  “Cost  Sharing”  of  6.1  by  ONR  Code  II 

There  is  a  special  category  program  under  ONR  Code  11,  popularly  called  “cost  sharing.”  Cost 
sharing  was  established  to  encourage  the  participation  in  Code  1 1  programs  by  Navy  Centers.  For  this 
program,  ONR  Code  11  holds  back  some  61153N  funds  to  assist  ONR  Technical  Officers  in  their 
sponsorship  of  especially  noteworthy  Navy  Center  research  proposals.  Near  the  start  of  the  Fiscal  year, 
ONR  Technical  Officers  present  their  proposals  for  the  cost-sharing  program.  These  proposals  are 
essentially  the  same  as  have  been  presented  to  the  Technical  Officers  by  the  Navy  Centers.  At  the  same 
time,  each  of  the  Centers  prepares  a  priority  list  to  submit  for  all  those  projects  that  the  ONR  Technical 
Officers  are  submitting  for  cost  sharing.  ONR  Code  1 1  then,  based  on  an  ONR  evaluation  and  Center 
priorities,  decides  which  projects  qualify.  For  “sharing  the  cost”  proposals,  additional  funding  equal 
to  that  already  earmarked  by  the  Technical  Officers  is  provided,  that  is,  funding  for  the  project  is 
doubled.  Those  Technical  Officers  who  do  not  succeed  may  still  support  the  Center  with  whatever 
funds  that  are  available. 

d.  6.1  Funding  from  ONR  Code  12 

The  6.1  money  that  ONR  Code  12  is  responsible  for  is  the  same  money  that  had  been  previously 
provided  by  ONR  to  the  SYSCOMs.  NOSC  expects  to  be  a  recipient  of  a  substantial  fraction  of  this 
6.1  money.  Individuals  are  encouraged  to  submit  proposals  to  ONR  Code  12  via  the  NOSC  Program 
Director  for  Research.  Discussions  should  take  place  as  early  as  possible.  The  ideal  time  to  submit 
proposals  to  ONR  is  in  the  spring  prior  to  start-up  of  the  next  fiscal  year  or  any  time  prior  to  1  October. 

e.  6.1  Funding  from  DARPA 

It  is  possible  for  NOSC  to  get  6.1  money  from  DARPA.  However,  DARPA  frequently  requires 
that  much  of  the  work  be  channeled  to  industry.  This  mode  of  operation  is  contrary  to  the  Research 
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Policy  of  NOSC  because  this  Center  must  observe  the  70/30  in-house/out-house  rule,  but  this  can  be 
partially  alleviated  through  the  use  of  RCPs.  This  work  often  involves  high  risk/high  payoff  efforts 
involving  special  accesses  and  can  often  provide  a  route  to  build  up  expertise  and  access  needed  for 
future  work  processes. 

f.  6.1  Funding  from  Army  and  Air  Force 

Our  sister  services  also  sponsor  research  with  6.1  Army  and  6.1  Air  Force  funds.  This  is  mostly 
administered  through  the  Army  Research  Office  (ARO)  or  the  Air  Force  Office  of  Scientific  Research 
(AFOSR).  Proposals  are  made  to  those  offices  or  other  Army  or  Air  Force  offices  which  they  may 
designate.  Such  proposals  are  made  directly  by  line  organization  personnel.  The  proposals  should  be 
for  good  basic  research  of  joint  interest  to  the  Navy  and  the  other  services. 

g.  6.3  Funding  Used  for  Research 

The  Strategic  Defense  Initiatives  (SDI)  Program  is  categorized  as  6.3  type  funds.  However,  under 
this  umbrella,  some  basic  research  is  done.  The  NOSC  Program  Director  for  Research  monitors  all 
SDI  Research  work  which  is  sponsored  in  the  Navy,  the  ONR,  and  in  the  other  services  where  it  is 
coordinated  through  ARO  or  AFOSR.  Such  work  is  on-going  at  NOSC. 

h.  Research  from  Other  Agencies 

It  is  permissible  to  make  research  proposals  to  other  federal  agencies  provided  the  work  is  of  interest 
to  the  Navy.  Currently  we  have  work  sponsored  by  NASA,  DOE,  and  other  agencies.  These  proposals 
are  made  on  a  case  basis.  They  must  necessarily  constitute  only  a  minor  fraction  of  the  NOSC  Research 
Program. 

4.5.2  Road  Map  for  6.1  Marketing  and  Proposals 

Figure  4. 1 1  indicates  where  6. 1  marketing  could  be  targeted  and  how  6. 1  proposals  should  generally 
be  reviewed/routed/submitted. 

Table  4.6  summarizes  possible  6.1  marketing  actions  and  the  timeframe  for  such  actions.  This 
is  included  to  guide  individuals  in  taking  6.1  actions  at  the  appropriate  time. 


4.6  EXPLORATORY  DEVELOPMENT  (6.2) 


4.6.1  6.2  Responsibility 

The  Chief  of  Naval  kesearch  (CNR),  Office  of  Naval  Technology  (ONT),  is  responsible  for  advisory 
and  oversight  of  the  Exploratory  Development  Program  of  the  Navy.  This  includes  preparation  and 
submission  of  the  Exploratory  Development  input  to  the  POM.  The  approximate  schedule  (may  vary 
somewhat  from  year  to  year)  for  getting  inputs  from  the  Block  Claimants,  and  for  conducting  the 
necessary  reviews,  and  finalizing  the  6.2  Program  is  shown  in  Figure  4.12. 


4.6.2  NOSC  Organization  for  6.2 

Figure  4.13  shows  the  NOSC  organization  for  managing  the  seven  Exploratory  Development  blocks 
for  which  NOSC  is  responsible. 
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Figure  4.11.  Marketing  and  proposals  (6.1)  by  NOSC. 


Table  4.6.  Summary  of  possible  6.1  marketing  actions  and  their  associated  timeframes. 

Possible  Action  Timeframe 

1.  Think  of/seek  out  good  research  items.  Continuous 

2.  Discuss  your  idea  with  the  NOSC  Program  Director  for  Research.  May  be  scheduled  at  any  time 

during  the  year,  but  the  ideal 
time  is  October  through  March. 

3.  Arrange  to  present  your  idea  for  informal  criticism  (e.g,  at  NOSC 
Program  Director  for  Research’s  “Research  Coffee.” 

4.  For  Independent  Research,  submit  a  preproposal  to  the  NOSC  April/May 
Program  Director  for  Research  in  response  to  the  Technical  Direc¬ 
tor’s  solicitation  for  such  proposals. 

5.  For  ONR  proposals,  informally  discuss  your  idea  with  ONR.  Spring  >r  anytime 
Ascertain  the  best  individual  to  contact  by  discussion  with  the 

Program  Director  for  Research. 

6.  Make  an  Informal  Proposal  to  ONR.  Discuss  first  with  the  Pro¬ 
gram  Director  for  Research. 

7.  Submit  a  Formal  Proposal  (DD  1498)  to  ONR.  Discuss  with  the 
Program  Director  for  Research  and  your  line  management. 

8.  Discuss  your  idea  informally  with  DARPA,  Air  Force,  or 
Army.  Consult  with  the  Program  Director  for  Research. 

9.  Make  an  Informal  Proposal  to  DARPA.  Consult  with  the  Pro¬ 
gram  Director  for  Research. 

10.  Make  a  Formal  Proposal  (DD  1498)  to  DARPA.  Get  assistance 
from  Program  Director  for  Research  and  concurrence  of  your 
line  management. 

11.  Discuss  possible  proposals  with  key  personnel  in  other  agencies 
that  sponsor  research  and  make  formal  proposals  to  those  agen¬ 
cies  in  whatever  format  they  specify. 
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4.6.3  Marketing  of  6.2 


Marketing  of  6.2  programs  should  be  conducted  primarily  with  the  Block  Managers  as  shown  in 
Table  4.7  and  Figure  4.13.  However,  as  shown  in  Figure  4.12,  the  SYSCOMs  review  and  comment 
to  ONT  on  the  Block  Plans  prepared  by  the  Lead  Laboratories/Claimants  necessitates  that  some  dialogue 
at  the  SYSCOM  level  be  initiated  depending  on  the  nature  of  the  project.  For  those  cases  where  the 
proposed  program  falls  under  the  cognizance  of  another  Block  Manager,  some  marketing  should  be 
conducted  at  that  activity.  (See  Appendix  4B  for  a  complete  list  of  Block  Plan  Managers  at  other 
Laboratories/Centers.) 


Table  4.7.  List  of  NOSC  Block  Plan  Managers. 


Technical  Area 

Block  Plan  Manager 

Code 

Command  Systems 

J.  Maynard 

402 

Communications  & 

Networking 

J.  Clapp 

808 

Computer  Technology 

R.  Wasilausky 

423 

Lasers  &  Micro¬ 
electronics 

I.  Lagnado 

5503 

Marine  Mammals 

H.  Porter 

51 

Ocean  Surveillance 

V.  Pusateri 

705 

Wide-Area  Undersea 
Surveillance 

D.  Hanna 

705 

NOTE:  These  individuals  are  (for  all  practical  purposes)  extensions  of  ONT  and  should  be  approached 
as  you  would  any  Washington  sponsor. 

4.6.4  Summary  of  6.2  Marketing  Actions 

Table  4.8  provides  a  summary  of  possible  6.2  marketing  actions  and  their  associated  timeframes. 
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Table  4.8.  Summary  of  possible  6.2  marketing  actions  and  their  associated  timeframes. 


Possible  Action 


Timeframe 


October-March 

October-March 
March-April  or  earlier 
April 

Mid-May 


1.  Discuss  your  proposed  6.2  with  the  appropriate  6.2  Block  Manager.  (See 
Table  4.7  for  a  list  of  NOSC  Block  Plan  Managers.) 

2.  Discuss  informally  with  potential  sponsor(s). 

3.  Develop  a  proposal  (LPS).  (See  Appendix  4C  for  sample.) 

4.  Have  your  proposal  reviewed  by  your  supervisor.  Informally  discuss  the 
proposal  with  NOSC  Block  Manager.  Obtain  in-house  clearance  for 
marketing  involving  Block  Plans  outside  NOSC. 

5.  Submit  your  proposal  formally  to  the  Block  Plan  Manager. 

6.  Prepare  the  Laboratory  Program  Summary  (LPS). 

7.  Prepare,  staff,  and  submit  a  Formal  Proposal  (LPS)  (except  DARPA). 
See  NOSC  Code  7405  for  DARPA  proposal  support. 

8.  Contact  the  NARDIC  Pasadena  Office,  AV  360  2452,  regarding  USAF 
or  Army  6.2.  NOTE:  Non-Navy/USMC  work  requires  the  TD’s  approval. 

9.  Participate  in  IR&D  reviews  as  an  aid  to  Technology  Base  marketing. 


4.6.5  Review  of  6.2  Marketing  and  Proposals 

Figure  4.14  depicts  the  procedure  for  review  and  submission  of  6.2  proposals  by  NOSC  technical 
personnel.  This  procedure  will  vary  with  the  nature  of  the  program  and  the  prospective  sponsor. 


Figure  4.14.  Marketing  and  proposals  (6.2)  by  NOSC. 
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4.7  ADVANCED  TECHNOLOGY  DEMONSTRATIONS  (6.3A) 


CNO,  OP-987,  administers  6.3A,  and  ONT  provides  advisory  support  to  OP-987  on  these  programs. 
Proposals  are  prepared  by  the  laboratories  and  shown  in  Figure  4.15.  ONT  evaluates  6. 3 A 
proposals  from  the  laboratories.  In  1987,  each  laboratory  was  limited  to  submitting  no  more  than  four 
6.3A  proposals  along  with  their  Block  Plans  (submitted  about  mid-July).  At  NOSC,  the  6.3A  proposals 
were  obtained  from  Department  Heads.  The  General  Board  voted  on  and  prioritized  the  proposals. 
Any  program  proposed  for  transition  from  6.2  to  6.3A  must  be  ready  for  such  transition  and  have 
strong  NOSC,  SYSCOM,  ONT,  and  OP-987  support.  With  creation  of  the  Balanced  Technology  Initiative 
(BTI)  program  and  Conventional  Defense  Initiative  (CDI)  programs  by  Congress,  there  is  increased 
opportunity  for  6.3A  high  risk/high  payoff  demonstrations.  These  programs  are  managed  by  OP-987 
as  adjuncts  to  their  regular  6.3A  program.  When  proposing  any  type  of  advanced  demonstration,  it 
is  critical  to  have  an  OPNAV  resource  sponsor  who  will  promise  to  pick  up  the  effort  at  the  completion 
of  a  demonstration,  given  that  it  is  successful.  Most  proposals  fail  due  to  the  lack  of  this  OPNAV  support. 

Non-Acquisition  programs  such  as  6.3A  must  follow  the  approval  process  outlined  in  OPNAVINST 
5000.42C  and  generate  Non-Acquisition  Program  Definition  Documents  (NAPDDs). 

4.8  SOURCES  OF  TECHNOLOGY  BASE  GUIDANCE/NEEDS 

The  following  are  recommended  documents  for  ascertaining  Navy  needs  as  pertain  to  the  Technology- 
Base  (6.1  and  6.2),  and  these  are  held  by  the  R&D  Planning  Guidance  Group. 

•  Fleet  R&D  Objectives/Deficiency  Reports 

•  Mission  Area  Strategies  (Guides  Exploratory  Development  (6.2)) 

•  Master  Plans 

•  OPNAV  Warfare  Appraisals 

•  Key  Naval  Needs  (Guides  Research  (6.1) ) 


LABS 


Figure  4.15-  Organization  for  6.3A  program. 
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I  4.9  ADVANCED  DEVELOPMENT  (6.3),  ENGINEERING  DEVELOPMENT  (6.4),  AND  <* 

OPERATIONAL  SYSTEM  DEVELOPMENT  (6.6) 

The  RDT&E  process  for  6.3, 6.4,  and  6.6  programs  and  those  developments  conducted  with  Program 
i  1,2,  and  3  funds  are  much  more  complex  than  for  the  Technology  Base  (6.1  and  6.2).  The  process 

is  not  centralized  such  as  the  Block  Plans  for  6.2.  The  process  for  6.3,  6.4,  6.6,  etc.,  will  be  covered 
in  this  section  only  to  the  extent  necessary  to  properly  address  the  marketing  and  proposals’  aspects. 

As  explained  in  OPNAVINST  5000.42C,  when  the  need  for  a  new  system  is  perceived  and  is  believed 
to  be  affordable,  OPNAV  transmits  to  the  appropriate  SYSCOM  a  Tentative  Operational  Requirement 
|  (TOR)  which  describes  the  needed  capability  in  genera!  terms.  All  TORs  are  sent  via  SPAWAR.  In 

response  to  the  TOR,  the  assigned  SYSCOM(s)  prepares  a  Development  Options  Paper  (DOP)  that 
contains  a  menu  of  options  from  those  of  minimum  capability  and  cost  to  advanced  systems  with  greater 
capability  and  cost.  All  DOPs  are  forwarded  to  OPNAV  via  SPAWAR.  OPNAV  then  selects  the 
alternative  that  best  matches  the  desired  capabilities  with  affordability  considerations.  OPNAV  then 
issues  an  Operational  Requirement  (OR);  for  Acquisition  Category  I  systems,  a  Justification  Major 
System  New  Start  (JMSNS)  is  also  issued.  When  an  OR  is  approved  by  OPNAV,  it  signifies  the  intent 
to  fund  the  acquisition,  and  the  sponsor  must  show  funding  in  the  POM  within  3  years,  or  it  automatically 
dies. 


Within  OPNAV,  a  TOR  or  OR/JMSNS  is  originated  and  submitted  by  the  cognizant  code.  It 
is  then  reviewed  within  OPNAV  by  those  codes  that  are  involved  or  have  an  interest.  The  TOR  or 
OR/JMSNS  is  then  approved  by  OP-098  and  promulgated  by  OP-098  as  explained.  Figure  4.16  shows 
the  organizational  structure  for  the  preparation  and  processing  of  TORs,  DOPs,  and  ORs/JMSNS. 


In  order  for  a  system  acquisition  to  be  included  in  the  Program  Objectives  Memorandum  (POM), 
there  must  be  an  approved  OR/JMSNS  for  that  system  by  1  January  for  the  upcoming  POM  year 
(the  on-year). 


Since  TORs,  DOPs,  and  ORs/JMSNS  are  needed  to  initiate  an  acquisition,  NOSC  should,  where 
appropriate,  assist  in  their  preparation. 

Additional  information  on  the  research,  development,  and  acquisition  procedures  is  contained 
in  OPNAVINST  5000.42C;  it  is  highly  recommended  that  it  be  studied.  See  Appendix  4A. 

NOTE:  The  use  of  Category  1 :  strategic;  2:  general  purpose  forces;  or  3:  C3I  funds  for  RDT&E 
is  a  sponsor-controlled  option;  the  process  is  roughly  the  same  for  all  programs  when 
viewed  from  a  NOSC  perspective. 


4.10  ON-GOING  AND/OR  PROGRAMS  TO  BE  INITIATED 


Consider  marketing  in  the  areas  of  6.3,  6.4,  and  6.6  by  trying  to  get  a  piece  of  a  program  that 
is  ongoing  or  is  just  being  initiated.  Getting  a  small  piece  of  a  larger  program  and  doing  it  well  often 
leads  to  a  larger  piece,  etc.,  and  builds  experience  with  lower  risk.  Again,  start  marketing  early  before 
all  the  pieces  have  been  assigned. 


4.11  TOP-LEVEL  WARFARE  REQUIREMENTS  (TLWR) 


TLWRs  are  relatively  new  and  are  described  in  detail  in  a  CNO  CONFIDENTIAL  memorandum, 
Serial  0905C/6C349644  of  18  Aug  1986.  They  provide  a  master  blueprint  for  future  operational  forces 
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Figure  4.16  Basic  organization  for  the  preparation  and  processing  of  TORs,  DOPs,  and  ORs/JMSNS. 


and  mission  areas  within  each  force.  The  objective  of  the  TLWR  process  is  to  provide  force- 
level  operational  requirements  that  enhance  multimission  capabilities,  drive  technological  development, 
and  pace  the  threat  into  the  2lst  Century.  In  the  future  it  is  expected  that  the  TOR/DOP/OR  process 
previously  described  will  be  preceded  by  the  TLWR  WSA/WSE  process. 

The  research,  development,  and  acquisition  process,  which  starts  with  a  Tentative  Operational 
Requirement  (TOR),  provides  a  force-level  frame  of  reference  for  development  of  requirements  to  be 
met  by  TORs  and  ORs.  Equally  important,  the  TLWR  process  provides  a  means  of  assessing  the  war- 
fighting  value  of  independently  generated  TORs  and  ORs.  The  TLWR  process  is  illustrated  in  Figure 
4.17.  Participating/assisting  in  the  TLWR  process  provides  marketing  opportunities. 


Figure  4.17.  The  TLWR  process. 
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4.12 


INTERNATIONAL  PROGRAM  FOR  NEW  INITIATIVES  (IPNI) 


4.12.1  General 

It  is  possible  to  obtain  6.2,  6.3,  6.4,  or  6.6  money  under  the  IPNI.  As  a  result  of  Congressional 
mandate  and  CNO  direction,  funding  is  available  for  several  new  IPNIs.  These  include  Foreign  Weapons 
Evaluation,  NATO  Cooperative  Test,  and  NATO  Research  and  Development  Programs.  Any  program 
proposed  under  the  IPNI  must  be  in  response  to,  or  in  support  of,  a  Tentative  Operational  Requirement 
(TOR),  an  Operational  Requirement  (OR),  or  a  Justification  Major  System  New  Start  (JMSNS).  Ir. 
order  to  get  a  6.2  program,  it  must  be  tied  to  a  system  or  other  for  which  there  is  a  TOR,  OR,  or  JMSNS. 


4.12.2  Areas  of  Preferred  Candidate  Proposals 


r 
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i 
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Proposals  for  doing  work  under  the  IPNI  are  desired  in  the  following  areas: 

•  Foreign  equipment  in  production  and  operation 

•  Equipment  that  has  a  performance  advantage  over  U.S.  systems 

•  Alternatives  to  U.S.  equipment  in  initial  development 

•  Projects  with  low  cost  and  with  high  payoff 

•  Willingness  of  foreign  governments/contractors  to  share  evaluation  costs 

IPNI  proposals  are  prepared  in  response  to  a  CNO  sponsor  request,  by  a  SYSCOM/ONR  initiative, 
or  as  a  Naval  activity  recommendation.  Figure  4.18  depicts  the  IPNI  proposal  submittal  and  approval 
process. 
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4.12.3  Sources  of  Information  for  Seeking  Out  Candidates 

The  following  are  recommended  sources  of  information  that  may  help  identify  a  candidate  for  1PNI:. 

•  Foreign  literature  from  Allied  countries 

•  Foreign  embassy  Naval  Attache  releases 

•  Technical  reports  from  information  exchange  projects 

•  Consolidated  listings  by  foreign  governments 

•  Vendor  brochures 

•  Foreign  periodicals 

•  Information  provided  to  the  Labs  by  SPAWAR  10F 


•  SECNAVINST  and  OPNAV1NST  3960  contain  detailed  information  on  the  IPNI  Program 
including  points-of-contact  within  OPNAV  and  the  SYSCOMs,  a  checklist,  and  formats. 

For  assistance  on  IPNI,  contact  the  office  of  the  Exploratory  Development  Program  Manager 
at  NOSC,  Code  014. 


4.13  JOINT  SERVICE  RDT&E 

OPNAVINST  5000.42C  strongly  encourages  the  use  of  a  joint  development  effort  for  those  programs 
where  there  is  a  commonality  of  requirements  between  the  Services  sufficient  to  support  a  common 
program.  This  should  be  considered  when  marketing  an  item  that  has  potential  for  joint  service  usage  | 
and  may  be  a  way  to  do  a  program  with  less  Navy  money.  ACAT  I  programs  will  automatically  be  ' 
required  to  be  submitted  for  consideration  as  joint  programs. 


4.14  MARKETING  OF  STUDIES  AND  ANALYSES 


« 


CNO  annually  develops  a  Study  Plan.  1  he  plan  lists  a  series  of  studies,  including  assignments 
of  responsibility,  aimed  at  deficiencies  made  apparent  in  the  process  of  preparing  the  Defense  Guidance. 
When  considering  proposing  major  study  efforts,  the  Study  Plan  should  be  reviewed  to  determine  if 
any  duplication  exists.  Inputs  to  the  Study  Plan  are  provided  by  OPNAV  and  the  SYSCOMs.  Major 
studies  and  analyses  should  be  marketed  similar  to  other  types  of  work.  The  Systems  Planning  Group, 
Code  16,  at  NOSC  has  the  responsibility  for  coordinating  NOSC  studies  and  will  advise  you  as  to  where 
to  locate  sponsors. 


4.15  Pn.i  SALS 


4.15.1 


This  section  includes  information  on  the  procedures  for  the  preparation,  review,  approval,  and 
submission  of  either  informal  or  formal  NOSC  proposals. 

Inform''! Proposal:  Any  document  submitted  to  a  sponsor  for  preliminary  review  and  critique  as 
a  prelude  to  ultimate  task  definition 
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Formal  Proposal:  A  document  submitted  to  a  sponsor  that  offers  to  perform  specified  work,  for 
a  specified  amount  of  funding,  within  a  specified  time 

Solicited  Proposal :  The  response  to  a  request  from  a  sponsor,  wherein  the  ultimate  decision  as 
to  whether  the  Center  will  receive  funding  to  accomplish  an  indicated  task  is  dependent  upon  the 
nature  and  quality  of  that  response 

Nonsolicited  Proposal:  The  submission  of  a  proposal  to  a  potential  sponsor  without  a  request  for 
such  a  proposal 

Submission  of  an  informal  proposal  is  in  no  sense  informal  marketing.  Despite  such  labels  as 
“preliminary,”  “informal,”  or  “working  papers,”  submission  of  a  documented  proposal  is  a  tacit 
offer  to  commit  NOSC  resources.  The  later  refusal  to  accept  an  assignment  because  of  lack  of  resources 
would  be  counterproductive  to  future  proposals.  Accordingly,  the  procedures  outlined  here  should  be 
followed  prior  to  initial  submission  of  any  type  of  proposal  to  a  prospective  sponsor. 

Informal  marketing  leading  to  submission  of  a  formal  proposal,  such  as  the  Laboratory  Program 
Summary  (DD  1498)  (see  sample,  Appendix  4C)  has  proven  to  be  effective.  Occasionally,  a  more  elaborate 
forma!  proposal  format  or  a  draft  Statement  of  Work  is  required  or  is  more  appropriate.  In  these 
instances,  the  NOSC  Proposal  Format  of  Appendix  4D  should  be  used. 

The  Commander,  NOSC,  has  the  sole  authority  to  commit  NOSC’s  resources  for  accomplisl.  •  .nt 
of  proposed  tasks.  All  such  commitments  are  required  to  be  reported  via  the  the  Laboratory  Program 
Summary  (DD  1498). 

In  order  to  anticipate  requirements  for  growth  or  attrition,  NOSC  management  must  maintain 
a  reasonable  estimate  of  new  business  prospects.  After  submission,  each  proposal  manager  will  be  asked 
to  report  periodically  on  the  status  of  proposals  pending. 

The  method  of  proposal  development  recommended  in  this  section  comprises  the  development 
of  an  informal  proposal  followed  by  a  formal  proposal.  Either  an  informal  or  formal  proposal  may 
be  solicited  or  nonsolicited.  Remember,  a  good  proposal  by  itself  is  insufficient  but  a  bad  one  is  “lethal” 
and  may  hurt  future  proposals. 

4.15.2  Developing  Proposals 

The  submission  of  an  informal  proposal  is  a  tacit  offer  to  commit  NOSC  resources;  do  not  oversell 
or  exaggerate.  Keep  in  mind  that  the  informal  proposal  creates  the  opportunity;  the  formal  proposal 
establishes  the  contract.  For  the  informal  proposal,  use  B&P  funding  (department  or  major)  or  current 
project  funding  if  for  the  same  sponsor  and  with  the  sponsor’s  knowledge.  This  process  takes  time; 
remember  that  your  goal  is  to  build  a  client/advisor  versus  a  customer/salesman  relationship.  The 
following  are  some  guidelines  for  developing  a  successful  informal  proposal. 

a.  Make  sure  the  proposal  is  of  “book”  quality,  that  is,  it  should  look  professional  but  not 
too  “slick.” 

b.  Develop  a  point  paper  or  self-narrated  brief.  It  must  skim  well.  Keep  it  short  and  profusely 
illustrated  (illustrations  should  have  instructive  captions).  It  should  appeal  to  experts  as  well 
as  laymen. 

c.  Remember  that  the  proposal  teaches  what  it’s  all  about.  It  establishes  or  creates  the  need, 
points  out  the  opportunity,  and  provides  the  solution.  It  establishes  the  theme  by  addressing 
the  superiority  of  the  approach.  It  should  consider  credibility,  risk  control,  timing,  cost, 
management  commitment,  and  the  defined  product  or  deliverable. 
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d.  Develop  the  briefing.  This  is  very  important— the  superiority  of  an  idea  or  design  is  not  so 
self-evident  that  it  does  not  require  supporting  data  and  presentations.  Therefore,  prepare 
a  first-class  briefing  designed  for  dialogue  with  the  customer.  Presentations  should  be  to  the 
point  and  be  presented  by  those  who  have  the  expertise  to  field  difficult  questions. 

e.  If  possible,  bring  some  or  all  of  the  following  items,  which  are  in  priority  order,  to  establish 
credibility  for  the  idea.  NOTE:  Items  from  the  top  of  the  list  support  the  argument  that  you 
are  farther  along  than  your  competition. 

Hardware 

Mockups 

Photos 

Engineering  type  drawings 
Artist  sketches 
Reports 
Data 

f.  Sell  the  theme  emphasizing  that  “we  are  farther  along.” 

g.  Detect/create  a  need/solution  that  the  customer  will  recognize  as  valid  and  that  is  not  available 
from  the  competition. 

h.  Offer  the  sponsor  something  he/she  can’t  get  elsewhere  such  as  special  experience, 
Fleet/intelligencc  access,  contracting  authority,  staff  support,  etc.  Know  the  competition’s 
strengths,  weaknesses,  tactics,  and  pricing  information.  Point  out  where  you  have  more  to 
offer,  but  don’t  “bad-mouth”  your  competition  (especially  if  it’s  in-house  or  at  another  Navy 
Lab.) 

i.  Know  the  leverage  points  (i.e.,  critical  thresholds,  costs,  etc.;  make  compromises  elsewhere 
to  preserve  these). 

j.  Cultivate  a  champion  at  headquarters  on  the  sponsor’s  staff;  treat  that  person  well;  invite 
the  sponsor  or  his/her  staff  to  NOSC  for  a  review  of  available  hardware  and  resources.  Use 
your  “champion”  to  gain  access  to  decision  matters  and  to  pull  decision  makers  together 
for  briefings,  etc.  Provide  your  “champion”  with  a  first-class  briefing  package. 

k.  Thoroughly  review  the  proposal  and  make  changes  that  will  improve  the  document. 

l.  Offer  to  assist  the  sponsor  and  the  sponsor’s  staff  in  performing  their  job,  writing  papers, 
documentation,  TORs,  etc.  When  you  go  to  a  sponsor  with  requests  for  action,  take  ready 
drafts  for  that  action. 

m.  Provide  your  sponsor  with  e-mail  capability  if  possible.  (It  is  an  excellent  way  to  provide 
drafts  and  staff  support.)  Telecopies  are  also  helpful. 

Several  things  should  be  kept  in  mind  when  developing  a  proposal.  First,  prior  experience  is  less 
important  than  the  best  proposal.  Second,  time  spent  on  a  good  presentation  pays  off  more  often  than 
additioral  analysis.  Be  sure  to  bring  in  additional  talent  to  the  team  as  the  requirements  unfold,  and 
additional  expertise  is  needed.  Brief  the  proposal  to  NOSC  upper  management,  if  appropriate.  Their 
commitment  and  interest  will  help  when  the  proposal  is  presented  to  the  sponsor. 
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4.15.3  Formal  Proposal 


The  following  observations  are  intended  to  provide  some  help  in  approaching  the  formal  proposal. 

a.  Use  the  Laboratory  Program  Summary  (DD  Form  1498)  format  and  seek  department 
administrative  support  when  preparing  a  proposal. 

b.  Identify  and  solidify  resources.  Verify  manpower  availability,  vault  space,  costs/schedule, 
and  obtain  necessary  signatures  and  letters  of  agreement. 

c.  A  cover  letter  is  most  helpful  (signed  out  as  high  as  possible  in  the  NOSC  chain  of  command 
to  show  management  support). 

d.  Large  programs  will  be  done  by  letters  of  agreement;  assignment  of  responsibility  to  (e.g., 
deputy  PM,  lead  Lab,  etc.).  These  will  need  your  staff  support  in  addition  to  writing  SOWs,  etc. 


4.15.4  Format  and  Contents  of  Proposals 

Appendix  4C  is  a  sample  of  a  Laboratory  Program  Summary,  DD  Form  1498.  The  1498  is  the 
official  record  of  NOSC’s  commitment  to  the  performance  of  any  given  task.  An  approved  1498  is 
required  for  each  on-going  project  and  is  necessary  for  funds  to  be  released. 

Appendix  4D  contains  information  on  the  format  and  contents  for  proposals  when  the  1498  cannot 
be  used.  Also  included  is  a  complete  description  of  each  item  of  such  a  proposal. 

For  those  cases  where  a  Statement  of  Work  is  required ,  the  format  and  contents  may  be  the  same 
as  for  a  proposal  (see  Appendix  4D)  but  more  detail  will  be  necessary.  (Some  activities  consider  the 
Laboratory  Program  Summary  as  being  too  brief  and  will  require  a  draft  Statement  of  Work.) 


4.15.5  Steps  for  Developing  and  Staffing  of  Proposals 

Appendix  4E  contains  a  step-by-step  procedure  for  the  planning,  preparation,  review,  submission, 
and  briefing  of  proposals. 


4.16  INITIATION  OF  NEW  PROJECTS 


When  the  Center  receives  a  task  assignment  and  funding  in  response  to  a  proposal  submission, 
the  approved  form  1 1ND-NOSC  3920/9  with  the  assigned  NOSC  project  number  constitutes  authority 
for  immediate  establishment  of  a  funding  resource  number.  When  task  assignments  are  received  as 
a  result  of  marketing  proposals,  a  1498  should  be  prepared.  When  task  assignments  arc  received  that 
are  not  the  result  of  a  proposal,  the  cognizant  department  head  will  ensure  that  suitable  technical  plan 
schedules  and  cost  estimates  are  prepared  and  incorporated  in  a  DD  1498,  plus  Form  1 1ND-NOSC-3920/9 
for  management  review  and  numbering.  The  department  head’s  signature  on  the  121ND-NOSC-3920/9 
certifies  that  he/she  has  positively  ensured  that  all  necessary  support  has  been  coordinated  with 
performing  divisions  and  departments.  These  completed  forms  are  the  official  record  of  NOSC’s 
commitment. 
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APPENDIX  4A 


POM-90  SCHEDULE  OF  EVENTS 


POM-90  SCHEDULE  OF  EVENTS 
EXAMPLE 


POM-90 

DUE  DATE 

EVENT 

LEAD/ 

ASSIST 

MECHANISM 

JULY  87 

Maritime  strategy  appraisal 

OP-06 

PDRC  and  CEB 

JULY- 
AUG  87 

Apportionment  Review  of  FY  88-89 

OP-92/ 

Claimants 

Meetings 

AUG  87 

C3I  Appraisal 

OP-094 

PRC 

AUG  87 

Revised  fiscal  guidance  for  Summary 
Warfare  Updates 

OP-90 

1  ocument 

AUG  87 

Submit  Extended  Planning  Annex 
(due  17  AUG) 

OP-91 

Document 

AUG/SEP  87 

Medical  Strategy  CEB 

OP-093 

Pre-CEB  and  CEB 

SEP  87 

Publish  RAD  V  and  RAD  VI 

•  Resource  allocation  display  of  SEPT 
DON  FYDP  (reflects  FY  88-89  appor¬ 
tionment  review) 

•  RAD  VI  forwarded  to  claimants 

OP -90 

POM  Serials  with 
computer  printout 

SEP  87 

MPT  Strategy  CEB 

OP-01 

Pre-CEB  and  CEB 

SEP  87 

Electro-magnetic  interference  (EMI)  CEB 

OP-094 

Pre-CEB  and  CEB 

SEP  87 

Non-nuclear  ordnance  (NNOR)  output 
briefings 

OP-095 

NNOP  board 

OCT  87 

Surface  Ship  Maintenance  strategy  CEB 

OP-03 

Pre-CEB  and  CEB 

OCT  87 

Navy  position  on  Theater  Nuclear  Warfare 
(TNW) 

OP-095 

Pre-CEB  and  CEB 

OCT  87 

Summary  Naval  Warfare  Appraisal  update 

OP-095 

PDRC  and  CEB 

OCT  87 

Investment  Strategy  Review  Update 

OP-91 

PDRC  and  CEB 

OCT  87 

Competitive  Strategy  Review 

OP-06 

PDRC  and  CEB 

OCT  87 

Implementation/Defense  Guidance  review 

OSD 

DRB  meetings 

NOV  87 

Training  CEB  (semi-annual) 

OP-01 

PDRC  and  CEB 

NOV  87 

Space  Appraisal 

OP-094 

PDRC  and  CEB 

NOV  87 

Distribute  outline  of  Draft  FY-89  Total 
Force  Report  to  Congress 

OP-06 

Document 

NOV  87 

Claimant  POM-90  issues  reviewed  and 
distributed  (due  1  NOV) 

OP-90 

Issue  papers 

NOV  87 

Unified  CINC  IPL  submission 
(due  11  NOV) 

OSD 

Documents 
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NOV  87 

Component  Commanders  POM-90  issues 
received  and  distributed  (due  1 5  NOV) 

OP-90 

Issue  papers 

NOV  87 

Planning  and  Programming  Guidance 
DSPB 

OP-90 

DON  Program 
Strategy  Board 

NOV  87 

OCT-DEC  87 

Issue  DON  Consolidated  Planning  and 
Programming  Guidance  (DNCPPG) 

Distribute  baseline  assessment  memoranda 
•  Costs  based  on  force  and  support  levels 
—Manpower,  Personnel  and  Training 
—Logistics,  including  BOS 
—Ship  Maintenance/Modern. 

—Naval  Reserve 

—Physical  Security  (non-BOS) 

—Mapping,  Charting  and  Geodesy 

OP-90 

OP-01 

OP-04 

OP-03 

OP-09R 

OP-09N 

OP-006 

POM  Serial 

Documents  only 

DEC  87 

Defense  Guidance  issued 
(30  DEC  is  target  date) 

OSD 

Memorandum 

JAN  88 

Reprice  MPN  for  RAD  VII 

OP-Ol/NMPC 

Memorandum 

JAN  88 

Publish  RAD  VII  and  RAD  VIII 

•  Resource  allocation  display  of  JAN 
FYDP 

•  RAD  VIII  forwarded  to  claimants 

OP-90 

POM  Serials  with 
computer  printout 

JAN  88 

Publish  CPFG 

•  Final  programming  guidance 

•  Fiscal  controls 

•  Guidance  to  sponsors  for  development 
of  SPPs 

OP-90 

POM  Serial 

JAN  88 

Medical  SPP  presentation 

OP-093 

PDRC/PRC 

FEB  88 

Joint  Service  Program  Briefings 

RS/OP-90 

Presentations  to 
other  services 

FEB  88 

Submit  Medical  Sponsor  Program 
Proposal  (SPP) 

OP-093 

Documents  and 
database  inputs 

FEB  88 

Draft  Medical  POM  review  by  DPSB 

OP-90 

DON  Program 
Strategy  Board 

FEB  88 

Complete  verification  of  database  update 
(medical) 

OP-90/ 

OP-093 

Examination 
of  computer 
printouts 

FEB  88 

Resource  sponsors  submit  heads-on  reports 
on  major  POM-90  program  requirements 
(to  provide  early  perspective  of  total 
program  requirements  during  Medical 
POM  DPSB) 

Resource 

Sponsors 

Documents 
(guidance  to  be 
provided  by 
separate  memo) 

FEB  88 

Provide  Initial  SCN/APN  Plans 

4-43 

OP-03/05 

Documents  and 
database  inputs 
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FEB-MAR  88 

Resource  Sponsors  Submit  Sponsor 
Program  Proposals  (SPP) 

OP-01 

OP-02 

OP-03 

OP-04 

OP-05 

OP-06 

OP-009 

OP-09B 

OP-006 

OP-094 

OP-095 

OP-098 

Documents  and 
database  inputs 

FEB-MAR  88 

Complete  verification  of  program  database 
update 

OP-90 

analysts/ 

Resource 

Sponsors 

Examination 
of  computer 
printouts 

FEB-MAR  88 

Submit  Sponsor  Program  Proposal 
Decision  Documents  (SPPDs) 

•  Each  resource  sponsor  responds  to  top 
five  issues  from  each  claimant  and  to  all 
component  commander  issues  which 
define  CINC  IPL  issues. 

Resource 

Sponsors 

OP-90  will 
forward 
documents  and 
resource  displays 
to  claimants 

FEB-MAR  88 

Issue  CNO  gj  J_nce  to  resource  sponsors 
for  EPA  development 

OP-91 

POM  Serial 

FEB-MAR  88 

OPN/WPN  displays  to  SYSCOMs  for 
repricing 

OP-92 

Computer 

printouts 

FEB-MAR  88 

SPP  Presentations 

•  Detailed  briefing/documentation 

•  OPs-90B/06/006/009  provide  documen¬ 
tation  only 

Resource 

Sponsors 

PRC/PDRC 

FEB-MAR  88 

CIVPERS  Review 

OP-90 

Examination 
of  computer 
printouts 

FEB-MAR  88 

Forward  Database  Displays  and  SPPDs  to 
claimants  for  review  and  comment 

OP-90 

Documents 

FEB-MAR  88 

SYSCOMs  deliver  OPN/WPN  repricing  to 
OP-92 

SYSCOMs/ 

OP-92 

Documents 

MAR  88 

Draft  Medical  POM  Submission  to 
OSD(HA) 

OP-90 

Memorandum 
with  computer 
printouts 
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MAR  88 


Distribute  Post-SPP  Assessments 


Memoranda 


—Manpower,  Personnel  and  Training 
—Logistics,  including  BOS  and  strategic 
—Ship  Maintenance/Modern. 

—Naval  Reserve 

OP-01 

OP-04 

OP-03 

OP-09R 

31 

—Physical  Security  (non-BOS) 
—Mapping,  Charting  and  Geodesy 

OP-09N 

OP-006 

l 

MAR  88 

OP-090/ Appropriation  Sponsor  Reviews 

OP-90/92 

Appropriation 

Sp  ‘i'>(  -s 

Meetings 

MAR  88 

Post  SPP  Training  Assessment 

OP-01 

PDRC  8 

MAR  88 

POM-90  DPSB  Review 

OP-90 

Briefing  to  DPSB  S 

by  resource  pillar  ^ 

MAR  88 

Final  reprice  of  MPN 

OP-12/NMPC 

Memorandum  f 

MAR  88 

Establish  final  manpower  controls 

OR-90/ 

OP- 12 

Memorandum  |  j 

s 

MAR  88 

Claimants  submit  SPP  comments/reclama 
to  OP-90 

Claimants 

Documents  ^ 

MAR  88 

POM  documentation  in  accordance  with 
POM  Preparation  Instructions  (PPI) 

Resource 

Sponsors 

Documents 

& 

MAR  88 

Submit  EPA  Platform  Procurement  Plans 

OP-02/03 

05/095 

Documents  to  * 

OP-91  ft 

MAR  88 

Database  lock  and  final  balancing 

OP-90 

Adjust  database  $ 

to  fiscal  controls  £ 

APR  88 

Submit  POM-90  to  OSD 

OP-90 

Letter,  database  jj« 

tape,  documents 

APR  88 

Publish  RAD  IX  and  RAD  X 

•  Resource  allocation  display  of  APR 
FYDP 

•  RAD  X  forwarded  to  claimants 

OP-90 

POM  Serials  with  ^ 

“  j 

APR  88 

Resource  sponsor  inputs  for  EPA 

Resource 

Sponsors 

Documentation  ^ 

MAY  88 

Submit  EPA 

OP-91 

Documentation  3 

JUN  88 

POM  90  program  review 

OSD 

DRB  meetings  -j 

JUL  88 

Final  program  decisions 
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APPENDIX  4B 


LIST  OF  BLOCK  PLAN  MANAGERS 
AT  EACH  NAVY  LABORATORY/CENTER 
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/V.  A'AV.V.V 


LV.V.V  V  *. 


HKNun  tuoPS 

tUCTIILE 

KOI  A 

irNSROC 

SURFACE  SHIP  IECHROLOGT 

*021 

irxsRsc 

SHIP  (  SUBItARIAE  HATERIALS 

XD2A 

I7HSR0C 

LOGISTICS 

ND3A 

ItNSRDC 

SUMAR1NE  TECHAOtOST 

E03A 

EOOTC 

EOD  TECHAOLOCT 

CC1A 

KOEC 

HARINE  CORPS  PROSRANS 

NAIA 

*A0C 

AIRBORNE  SURVEILLANCE 

NAtf 

NACC 

AIR  PLATFORAS  t  STSTEAS 

NA2A 

NAOC 

AIRCRAFT  HATERIALS  TECHNOLOGY 

*A2I 

*ADC 

NAVIGATION  t  A/C  C3 

XA3A 

XAOC 

AIR  ASH  SURVEILLANCE 

WV1A 

HAVA1R 

NAVAL  AIR  VEHICLE  TECHNOlOST 

HV2A 

XAVA1R 

ADVANCED  AIRCRAFT  HATERIALS 

TE2A 

NAVFAC 

FACILITIES  I  ENVIRON  PROTECTION 

SS3A 

NAVSEA 

NUCIEA*  PROPULSION 

TP2A 

AAVSUP 

PROTECTIVE  CLOTHING 

KC3A 

KCSC 

NINE  CH/TORPEOO  CN/SPEC  H/F 

EP2A 

KEPRf 

ATHOSPHFRIC  SUPPORT 

n02A 

wiROC 

REDICAl  CBR  DEFENSE  1  B I OREO  TECH 

oe?A 

NOBS 

ASTRONONT 

RD2A 

KORDA 

OCEANOSRAPHIC  SUPPORT 

R03A 

NOROA 

ENVIRONRENTAL  ACOUSTICS 

N01A 

*0SC 

1NIEGRATED  OCEAN  SURVEILLANCE 

N02A 

kOSC 

LASERS  1  HICP.QEIECTRONICS 

*028 

HOHC 

CONAUNICATIONS  l  NETWORKING 

*02C 

*0SC 

COHTANO  STSIENS  TECHNOLOST 

*020 

m: 

COMPUTER  TECHNOLOST 

N03A 

K03C 

HIDE  AREA  UNDERSEA  SURVEILLANCE 

*038 

west 

NARINE  RAKRALS  TECHNOLOST 

*-2A 

*PRCC 

PERSONNEL,  TRAINING  l  HUNAN  FACTORS 

ALIA 

*Rl 

SPACE  TECHNOLOST 

RUB 

HPL 

SURFACE  SURVEILLANCE 

RUC 

HRL 

ELECTRONIC  WARFARE 

PL2A 

*PL 

LASER  HARDENED  HATERIALS 

RL2B 

NRL 

HH/K1U/E0  TECH  l  ELECTRONIC  SATIS 

RL2C 

KRL 

DECISION  SUPPORT 

PL3A 

NHL 

ASH  SUPPOPT  TECHNOLOGIES 

H3IA 

KSilC 

SIIRr  ace  launched  heaponrt 

*32A 

N5WC 

NEAFOKS  HATERIALS 

*323 

ASK 

CSP  DEFENSE 

NS3A 

N3K 

EXPLOSIVE:  l  UNDERSEA  WARHEADS 

N33B 

H3HC 

NINES 

NT2A 

*!SC 

SIBILATION  1  TRAINING  DEVICES  TECH 

NU2A 

nose 

SUBNARINE  CONHUNTCATIOHS 

HU3A 

*usc 

TORPEDO  PROPULSION 

*U3B 

«usc 

supnapine.'su'-'ace  Shi'  »sw  siiRv-::-.. 

*’J3C 

KU5C 

COHBA-  LONT-OL 

NW|A 

su: 

.aunche:  wEpooNA’ 

n«:a 

in: 

NlSEil-  SU”0?T 

qp:a 

0*P 

aah/ASUN  1  SUPfAK/ASROSPACE  TECH 

GR2A 

0*P 

SUPPORT  TECHNOLOGIES  »R06RAH 

0R2I 

0*P 

FINANCIAL  HOT  l  HOBILITT 

0F.3A 

ONR 

NON-ACOUSTIC  ASH 

OR  31 

ONR 

ASH  t  UNDERSEA  TECHNOLOST 

on* 

OHT 

SPECIAL  TARGET  RADAR 

0T3A 

0*1 

ADVANCED  U.'S  WEAPONS  G  i  C 

oral 

ONT 

HIGH  GAIN  STSTEHS 

10IA 

SPAHAR 

TACTICAL  DIRECTED  ENERGY  TECH 

IA2A 

SPAHAR 

AGED  SUPPORT 

IITA 

SPAHAt 

SEACON 

ID3A 

SPAHAR 

ARIADNE 

IITA 

SPAHAR 

NSAP 

OTTA 

ONT 

POSI-DOC  FELLOWSHIP  PROS 

OITA 

ONT 

LABORATORY  IED  PROGPARS 

HSRNAHE 

R6R0R6CDDE  HSPPHONE  0RGCJ1T 

op.iup 

Hr  Lincoln  Cithers 

012.4 

202-221-1378  lethesda  HD 

20084 

Hr  Ivu  Cap I  an 

0I2.S 

30I-267-2G3G  lethesdi  HO 

20CG4 

Hr  Joseph  Sheehsn 

012.G 

202-227-1028  lethesdi  HO 

20084 

Hr.  Lincoln  Cathers 

012.4 

202-227-1378  Pethesdi  HD 

201)84 

COL  1  lalles,  USHC 

D0G2 

Otto  Kessler 

508 

2I5-44I-15G3  Hiroinster  PA 

13574 

ten  Green 

60CI 

215-441-1375  Hir.inster  PA 

18974 

Irv  Shalfer 

G0C2 

215-441-2824  Hir.inster  PA 

18974 

Halt  Shoppe 

401 

2I5-44J-237B  Hir.inster  PA 

18974 

Ton;  Rader  1 

SOD 

215-441-1067  Hariinster  PA 

18974 

tlilon  Essogloa  703-325-8533 

<M  Pina.a  CiS)  FL  32-507 

Rcnterer  CA  03343 


Hr  Vincent  Pusileri 

705 

Dr  Isaac  Lagnado 

5503 

Dr  Gerald  Clapp 

80B 

Hr  Jonn  Naynard 

‘02 

Hr  SoSe't  Wastlaasky 

422 

Hr  Dear.  Hanna 

705 

Hr  Hoeer  Porter 

5) 

hr  Orv  Larson 

Peter  Uilhelo 

770D 

Or  Hernll  Srolnik 

Or  Jonr.  Hontgoif-; 

Dr  Dated  Napel 

6G00 

Dr  Geralc  Eo'sal 

6500 

Dr  Jonr.  R  Davis 

7500 

Dr  David  Bradley 

Hr  Danny  Bruns"n 

GOG 

Or  Hilltar  Rt's.ct 

F2D5 

Hr  Jot  Bru.fiels 

H3I 

Hr  Donald  Phillips 

R!PA 

Hr  Ronald  Tipton 

U04| 

Scte-t  Breaai 

.c->.-  Da.- s 


'  -  ?**•» 

Or  To.  .attas 

Olio 

Dr  Richard  Whiting 

123 

CAPT  E.C.  Craig 

122 

Or  Cowarts  lis:ki  ARL/PSU  AR3A” 
Hr* til  tooth 


COP  t  E  Ev.ns  PDWJ24-7 


615-225 -5711  San  Diego  CA 

$21:2 

615-225-5725  San  Diego  CA 

32152 

6!5-:25-:044  San  Diego  CA 

32152 

613-225-5614  $an  Diego  CA 

92152 

613-225-2083  5an  Diego  CA 

92152 

613-225-5545  San  Diego  CA 

92152 

6! 3-225-2365  3an  Diego  CA 

92152 

613-225-5400  San  Diego  CA 

52152 

202-767-5547  Washington  DC 

20375 

202-767-2336  Washington  DC 

20275 

202-767-6278  Washington  DC 

20375 

202-767-232!  Hasnington  DC 

20375 

202-757-3525  Washington  PC 

2037' 

:02-7b7-2302  Washington  DC 

2'1775 

202-767-3432  Washington  DC 

20275 

702-553-8211  Dahlgren  VA 

22*  iB 

202-394-1137  Silver  Ss'tnj 

HP  7C9E-2 

702-662-8521  Danlgrer.  VA 

22*48 

2 94 -251$  Sliver  Sprinc  flO  29902 

202-234-127:  Stive-  Sprjn; 

NO  2,',r3 

» TV  -«<=:  5 nandr  K 

775:7 

*»v  .onoor.  *.T 

06270 

Nevnprt  Rl 

*•»  .ondon  3T 

96275 

Nevport  RI 

A.'V  437-3541  China  Lake  CA 

32555 

A/V  437-2241  China  Lake  LA 

32555 

Arlington  VA 

22217 

Arlington  VA 

22217 

Arlington  VA 

22217 

202-696-47J3  Arlington  VA 

22217 

202-536-4713  Arlington  VA 

22217 

Arlington  VA 

22217 

814-946-432!  State  College  PA  16Bn4 

Arlington  VA 

22217 

Washington  DC 
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APPENDIX  4C 

SAMPLE  OF  A  LABORATORY  PROGRAM  SUMMARY  (DD  1498) 


I 


OAWICJtTON 

U 
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a  .(rwmn .  w<— .  e Kep  Ocean  Technology?  (U)Mine  Countermeasures  Equipment; 
(U)Remotely  Controlled  Undersea  Vehicles; _ 


23, (U)OBJECTIVE.  Provide  NAVSEA  design,  fabrication,  test  and  product  assurance 
support  in  several  areas  relating  to  the  development  of  the  Mine  Neutralization 
System. 


24. (U) APPROACH.  NOSC  is  Technical  Direction  Agent  (TDA)  for  MNS  Program,  and  is 
responsible  for  following  tasks:  a)  assist  NAVSEA  in  directing  contractor  for  MNS 
production  and  b)  maintain  drawing  baseline. 


25. (U)PROGRESS( Jan-May  86).  Technical  agent  activities  were  continued.  Monitoring  of 
the  Honeywell  production  contract  involved  attendance  at  several  management,  design 
review  and  test  planning  meetings.  Documentation  was  reviewed  for  the  production 
contract  of  MNS.  Evaluation  of  engineering  change  proposals  (ECPs)  for  drawing 
correction  and  design  improvement  continues.  Other  contract  delivery  line  items 
(CDRLs)  are  being  reviewed.  Preliminary  component  and  systems  tests  have  started  on 
the  second  two  units.  Factory  acceptance  tests  were  completed  on  the  first  system. 
Handling  system  redesign  for  a  low  magnetic  signature  was  completed  and  the  first  two 
systems  shipped.  One  handling  system  was  shipped  to  mine  countermeasures  Ship  2 
(MCM-2). 
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JS.  BACKGROUND.  30.  PLANS  ANO  MILESTONES.  31 .  REFERENCES.  33  MAjOR  CONTRACTS.  31  SPECIAL  REQUIREMENTS 

29. (U) BACKGROUND.  Current  nine  neutralization  aethods  employ  vectored  surface  craft 
carrying  neutralization  charges  to  disable  bottom  mines.  Moored  mines  generally  are 
cleared  using  a  variety  of  mechanical  and  influence  sweep  gear.  Certain  mines  may  be 
more  readily  amenable  to  neutralization  through  the  uso  of  a  tethered  remote 
controlled  vehicle  capable  of  dropping  a  charge  on  a  bottom  case  or  attaching  a  cable 
cutter  to  a  mooring  line.  Such  a  vehicle  would  be  deployed  from  a  fleet  Ocean 
Minesweeper  with  a  store  of  cutters  and  charges  for  extended  and  repeated  operations 
consuming  less  time  per  neutralization  than  with  conventional  aethods. 


30. (U) PLANS  AND  MILESTONES. 


FY86.  Assist  NAVSEA  in  direction  of  the  MNS  Production  Contractor.  Transition 
drawino  baseline  to  Naval  Mine  Warfare  Engineering  Activity  (NMWEA)  York town,  va. 


31 .(U)REFERENCES. 


1.  N0C  TN  675,  Remote  Controlled  Vehicle  Mine  Neutralization  System  (U), 
CONFIDENTIAL,  Code  6512,  Feb  1972. 

2.  NCSL  Report,  Design  Tradeoff  of  a  Controlled  Underwater  Neutralization 
Vehicle  System  (U),  CONFIDENTIAL,  Feb  1972. 

3.  NAVSEC  Specification  6127-1A,  Development  Specification,  Mine  Neutralization 
Vehicle  System  (U),  CONFIDENTIAL.  15  May  1972. 

4.  NOC  TN  1350,  Mine  Neutralization  Vehicle  System  Magnetic  Signature  and 
Analysis  (U),  CONFIDENTIAL,  T.  J.  Keil,  Jr.,  May  1974. 
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1.  ‘SUMMARY 


The  Summary  is  the  last  portion  of  the  proposal  to  be  written.  It  can  sometimes  be  combined 
with  the  Introduction  very  effectively. 

1.1  GENERAL 

Convince  the  prospective  sponsor  very  quickly  that  NELC  is  competent  in  all  respects  and  fully 
able  to  meet  their  requirements.  Appeal  to  the  sponsor’s  own  self-interest  by  highlighting  those  key 
benefits  (three  or  four  at  the  most)  which  he/she  will  get  by  selecting  NELC  to  perform  the  program. 
(BE  BRIEF— one  or  two  pages.)  This  summary  should  quickly  answer  the  what,  how,  and  why  of 
the  proposal. 

1.2  ‘OPERATIONAL/TECHNICAL  REQUIREMENTS  (what) 

a.  We  are  going  to  take  steps  in  solving  the  problem,  etc. 

b.  Length  of  time  work  will  be  conducted  is _ ,  and  the  expected  results  are _ etc. 

1.3  PROPOSED  PLAN  (how,  brief) 

Some  examples  of  lead-ins  are 

a.  We  will  supply  five  highly  qualified  engineers  to  implement  the  task  at  hand. 

b.  We  will  conduct  the  effort  at  NELC. 

c.  We  will  travel  to _ to  gather  data  for  evaluation. 

1.4  NELC’S  POSIi;ON  (why) 

Some  examples  of  why  NELC  should  do  this  job  are 

a.  The  assignment  of  highly  qualified  personnel  will  be _ 

b.  Solid  experience  in _ . 

1.5  DELIVERABLES  (Provide  a  brief  de^rlption  of  the  major  deliverables.) 


♦Minimum  requirement  for  proposals 
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2.  INTRODUCTION 


2.1  GENERAL 


The  purpose  of  this  section  is  to  introduce  the  proposal  in  terms  of  content  and  plan.  Briefly  outline 
the  basic  points  of  the  proposed  program  and  the  philosophy  underlying  the  approach.  (This  must 
set  the  stage.) 


a.  Purpose  of  this  document. 

b.  Other  relevant  information. 


3.  PROBLEM 


3.1  STATEMENT  OF  THE  PROBLEM 


This  should  be  from  an  operational  point  of  view  in  terms  of  satisfying  the  user’s  requirements. 
This  is  the  “what”  of  the  story  rather  than  the  “how.” 


A  thorough  discussion  of  the  sponsor’s  requirements  should  be  provided  along  with  what  NELC’s 
program  will  provide  (objectives).  Factors  such  as  compatibility,  reliability,  and  maintainability  should 
be  emphasized. 

Present  sponsor’s  nroblem  from  a  technical  and  economic  standpoint.  Set  forth  reasons  which 
govern  your  proposed  approach  (reasons  which  make  your  choice  valid).  These  must  cover 

General  discussion  of  overall  requirements 

Satisfying  overall  requirements 

c.  Discussion  of  specific  requirements 

d.  Satisfying  specific  requirements 

e.  Discussion  and  validation  of  derivation 


a. 

b. 


f.  System  concepts 


3.2  COMPLIANCE  STATEMENTS 


A  statement  of  compliance  or  noncompliance  with  relevant  specifications  or  requirements.  AH 
unrealistic  or  unreasonable  performance  requirements  should  be  identified. 
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4.  APPROACH 


4.1  GENERAL 

This  is  the  “how”  of  the  proposal.  It  should  have  a  simple,  easily  followed  theme,  and  the  solution 
should  be  described  step  by  step.  The  proposal  task  may  be  subdivided  into  subtask  1 ,  subtask  2,  etc. 


4.2  PRODUCT  DESCRIPTION 

a.  Technical  Description.  Provide  a  clear  and  accurate  technical  description  of  the  hardware  or 
system  visualized.  This  should  include  drawings,  sketches  or  diagrams  where  appropriate  (avoid 
unnecessary  repetition  of  information  contained  in  the  sponsor’s  proposal  request).  Identify 
technical  data,  if  any,  to  be  provided  with  hardware  deliverables.  Identify  Government  Furnished 
Equipment  (GFE)  required  to  support  the  proposed  effort. 

b.  Uniqueness  of  Design,  Process  or  Application.  Describe  any  segment  of  the  approach  that  is 
believed  to  be  unique  in  design,  process,  or  application.  Also  indicate  any  previous  successful 
application  of  the  concept.  Emphasize  the  benefits  to  the  sponsor. 

c.  Alternate  Approaches.  If  applicable,  briefly  discuss  alternate  approaches  which  have  been 
explored  and  rejected  and  the  primary  reason  for  rejection. 

d.  Relevant  Specifications/Standards/Instructions.  Identify  relevant  specifications  or  standards 
which  will  be  met.  Take  exception  to  unrealistic  or  unreasonable  performance  requirements 
and  deviations  from  specifications. 

e.  Areas  of  Risk.  Clearly  point  out  areas  of  significant  risk  with  regard  to  performance,  schedule, 
or  cost,  and  explain  reasons  therefore. 


4.3  TEST  PLAN 

Plans  for  technical  and  operational  evaluations  must  be  addressed  separately  as  follows: 

a.  Technical  Evaluation.  Discuss  the  nature  and  duration  of  testing  planned  for  technical 
evaluation  of  product,  including  test  specifications  or  standards  to  be  met.  Identify  special 
test  equipment  available  or  required. 

b.  Operational  Evaluation.  Discuss  the  nature  and  duration  of  testing  planned  for  operational 
evaluation  of  product  (reliability,  maintainability,  human  factors,  etc.),  including  test 
specifications  or  standards  to  be  met. 


4.4  QUALITY  ASSURANCE  PLAN 

If  the  project  involves  hardware  that  will  go  to  the  Fleet  for  evaluation  or  permanent  installation, 
a  quality  assurance  plan  must  be  addressed.  The  plan  should  discuss  applicable  specification  requirements 
(MIL-Q-9858  or  MIL-I-45208)  and  any  e\ceptions  to  those  specifications.  Discuss  applicable  sections 
of  NELCINST  4855.2  (Quality  Assurance  Manual)  and  how  they  apply  to  the  project  deliverables. 


4.5  MAINTENANCE  AND  SUPPORT 


When  included  as  part  of  the  specifications,  provide  a  description  of  proposed  plan  for  satisfying 
the  maintenance,  support,  personnel  and  training  requirements  of  the  hardware  or  system  proposed. 
This  description  may  serve  as  a  foundation  for  development  of  a  support  program  concurrent  with 
development  of  the  hardware  or  system.  Discuss: 

a.  Number  of  types  of  personnel  required  for  maintenance 

b.  Description  of  any  new  or  special  skills  required 

c.  Depth  and  duration  of  material  support,  initial  provisioning  spares,  rotational  or  replenishment 
spares 

d.  Tool  and  test  equipment  requirements  for  product  support 

e.  Publications  and  documentation  packages  for  operational  test  and  checkout,  daily  servicing, 
scheduled  and  unscheduled  maintenance,  component  repair  and  rework 


4.6  SCHEDULE 

This  section  will  of  necessity  vary  from  proposal  to  proposal.  However,  as  a  minimum  the  following 
points  must  be  addressed: 

a.  Provide  a  graphic  schedule  of  activities,  events  and  milestones  of  specific  accomplishments 
•'nticipated.  Indicate  in  time  frames  when  study  tasks  will  be  concluded,  when  preliminary 
or  final  system  design  is  completed,  etc.  Provisions  should  be  made  for  periodic  review  and 
evaluation  at  appropriate  intervals. 

b.  A  brief  narrative  of  each  event  should  be  included. 

c.  List  the  type,  scope,  frequency  and  issue  dates  of  technical  progress  reports  planned. 

d.  List  of  deliverable  items,  including  data  items  listed  on  form  DD-1423  with  accompanying 
Data  Item  Description,  form  DD-1664. 


i 

I  5.  MANAGEMENT 

i 


|  5.1  GENERAL 

i 

[  This  section  should  reflect  three  logical  a-eas:  (1)  organization,  (2)  manpower  projection  or  phasing, 

and  (3)  personnel.  This  section  explains  NLLC’s  organization  and  how  the  proposal  team  relates.  It 
finally  introduces  the  personnel  who  will  actually  work  on  the  project. 

! 
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5.2  ORGANIZATION 


Show  the  current  NELC  organization  together  with  the  program  and  technology  organizations 
respectively.  Also,  show  the  proposed  organization  structure  that  will  provide  the  support  for 
accomplishing  the  proposed  task.  Organization  structures  should  be  in  the  format  as  provided  in 
NELCINST  5400.24. 


5.3  MANPOWER  PROJECTION 

Information  concerning  manpower  projection  should  be  provided  by  man-month  or  man-years, 
as  applicable.  Following  is  an  example  of  the  type  of  manpower  data  needed. 

MANPOWER  PROJECTION 
MAN-MONTHS  AFTER  TASKING 


Title 

1 

2 

3 

4 

5 

6 

TOTALS 

Project  Manager 

.5 

.5 

.5 

.5 

.5 

.5 

3.0 

Task  Manager 

1.0 

1.0 

1.0 

1.0 

1.0 

1.0 

6.0 

Electronics  Engineer 

2.0 

3.0 

3.0 

3.0 

2.0 

1.0 

14.0 

Product  Assurance  Engineers 

.5 

1.0 

1.0 

1.0 

1.0 

.5 

5.0 

Programmers 

1.0 

2.0 

2.0 

2.0 

1.0 

1.0 

9.0 

Program  Analyst 

_A 

_A 

_A 

_A 

_A 

_A 

.6 

TOTAL 

5.1 

7.6 

7.6 

7.6 

5.6 

4.2 

37.6 

5.4  MANAGEMENT  PLAN 

Define  the  management  plan  for  implementation  of  the  proposed  task.  Items  covered  should  address, 
but  not  be  limited  to,  the  following 

a.  Program  Planning  and  Control 

b.  Work  Breakdown  Structure  (WBS) 

c.  Milestones 

d.  Time  Dependence  Chart 

e.  Financial  Plans 

f.  Configuration  and  Data  Management 

g.  Integrated  Logistic  Support  (ILS) 

h.  Quality  Assurance  Management 

i.  Reliability 

j.  Test  and  Evaluation 


6.  EXPERIENCE 


6.1  GENERAL 

This  section  is  of  significant  importance  for  it  is  a  credential  of  capability.  It  should  describe 
experience  on  similar  or  related  projects  and  should  be  tailored  specifically  for  each  proposal. 


6.2  NELC  EXPERIENCE 

Describe  how  existing  equipment  and  systems  in  which  NELC  is  now  engaged,  or  has  successfully 
completed,  may  be  applied  or  related  to  the  techniques  and  hardware  to  be  developed  under  this  proposal. 


6.3  KEY  PERSONNEL 

a.  List  only  those  key  persons  who  may  be  assigned  to  work  on  the  project  starting  with  project 
manager,  task  manager,  electronics  engineer,  etc. 

o.  Identify  personnel  considered  outstandingly  qualified  in  the  specific  technical  areas  involved. 
Attach  a  “typical”  resume. 

c.  List  previous  experience  of  each  in  the  specific  technical  area  or  related  areas.  Include  number 
and  type  of  degrees  held,  professional  and  honor  societies,  patents  held,  awards,  etc. 


7.  FACILITIES  AND  SECURITY 


7.1  GENERAL 

This  section  describes  NELC  facilities  available  for  the  proposed  task  and  the  security  measures 
that  will  be  used  to  safeguard  the  program. 


7.2  FACILITIES 

a.  List  and  discuss  facilities  available  at  NELC  which  are  planned  for  use  in  conducting  necessary 
research,  development,  production  and  testing  required  in  the  program.  Cite  savings  to  sponsor, 
when  applicable,  if  availability  of  unique  facilities  reduces  procurement  costs. 

b.  Include  description  and  estimated  procurement  cost  and  delivery  schedule  for  additional  facilities, 
equipment  or  special  tooling  which  will  be  required. 
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7.3  SECURITY 

Indicate  security  levels  and  how  they  will  be  safeguarded.  Reference  can  be  made  to  DoD  INSTR 
5220.22-M,  Industrial  Security  Manual  for  Safeguarding  Classified  Information.  Also,  mention 
application  of  the  Security  Manual,  NELCINST  5500  6. 


8.  COST  SUMMARY 

Note:  The  cost  summary  may  be  separately  bound. 


8.1  GENERAL 

This  section  of  the  proposal  summarizes  the  costs,  labor,  and  travel  requirements  to  perform  the 
proposed  task. 

The  amount  and  type  of  data  will  usually  be  specified  in  the  sponsor’s  proposal  request.  If  a  cost 
breakdown  is  not  specifically  requested,  costs  should  be  as  general  as  possible.  An  outline  of  detailed 
cost  elements  is  provided  for  planning  purposes. 


8.2  LABOR  COSTS 

Labor  charges  should  reflect: 

a.  Man-hours  in  categories  such  as  project  manager,  task  manager,  electronics  engineer,  etc. 

b.  Costs  to  include  hourly  rates  and  totals 

c.  Overhead  rates  for  each  category 

d.  Outside  labor  should  state  hourly  rate  to  be  charged  for  contractor  personnel  (if  any),  and 
total  contractor  support  to  be  provided 


8.3  TRAVEL  COSTS 

a.  Commercial  Travel 

b.  Local  Travel 

c.  Per  Diem 
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8.4  SUPPORT  COSTS 


a.  Graphics 

b.  Photo  Branch 

c.  Computer  Time 

d.  Duplication  Charges 

e.  Other 

8.5  MATERIAL  COST 

List  estimated  cost  for  material. 

8.6  MAJOR  PROCUREMENTS 

a.  List  line  item  description 

b.  List  estimated  cost  for  each  major  procurement 

8.7  ADDITIONAL 

Additional  workhour  and  material  requirements;  include  statement  to  cover  any  contingencies. 

8.8  TOTAL  COSTS 

List  total  costs  to  complete  proposed  task. 

9.  ABBREVIATIONS  AND  NONSTANDARD  TERMS 

9.1  GENERAL 

Following  is  a  list  of  abbreviations  and  non-standard  terms: 

9.2  DEFINITIONS 


Terms 


Definition 
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APPENDIX  4E 


STEP-BY-STEP  PROCEDURE  FOR  PREPARATION 
AND  STAFFING  OF  PROPOSALS  BY  NOSC 


1.0  STEP-BY-STEP  PROCEDURE  FOR  PREPARING  AND  STAFFING  PROPOSALS 


1.1  GENERAL 

It  is  recognized  that  each  marketing  opportunity  is  unique,  and  proposal  events  peculiar  to  any 
one  opportunity  may  require  a  deviation  from  standard  sequences.  Nevertheless,  the  intent  of  Figure 
4E-1  is  to  provide  a  guide  for  the  preparation  of  a  proposal.  It  is  the  responsibility  of  every  manager 
involved  to  ensure  that  deviations  from  the  standard  sequence  do  not  result  in  serious  curtailment  of 
these  interactions.  The  steps  that  follow  are  keyed  to  Figure  4E-1. 


1.2  RECEIPT  OF  PROPOSAL  REQUEST  OR  REQUIREMENT  (Block  A) 


a.  Proposal  development  procedures  normally  begin  with  the  receipt  of  an  informal  or  formal 
proposal  request  or  the  receipt  of  a  formal  or  an  informal  requirement. 

b.  Informal  Proposal  Request.  Most  NOSC  proposals  result  from  verbal  requests  made  during 
informal  marketing  contacts  with  sponsors.  If  any  doubt  exists  regarding  the  appropriateness 
of  the  requested  management  code,  the  cognizant  program  office/division  head  should  refer 
the  matter  to  the  department  head(s)  concerned  for  resolution  before  proceeding  further. 


c.  Formal  Proposal  Request  Addressed  to  a  Specific  NOSC  Code.  The  great  majority  of  formal 
(documented)  proposal  requests  received  by  NOSC  indicate  a  particular  code  which  the  sponsor 
desires  to  manage  the  proposed  task.  In  these  instances,  the  mail  room  will  forward  the  proposal 
request  directly  to  that  code  for  action,  with  information  copies  to  the  cognizant  department 
head.  If  any  doubt  exists  regarding  the  appropriateness  of  the  cognizant  management  code, 
the  matter  should  be  resolved  by  the  department  head(s)  involved  and/or  the  Technical  Director 
before  proceeding  further. 


d.  Formal  Proposal  Request  Addressed  to  NOSC.  On  occasion,  NOSC  receives  a  formal  Proposal 
Request  with  no  indication  of  desired  performing  code.  In  such  cases,  the  Proposal  Request 
will  be  referred  to  the  appropriate  department,  divisiou,  or  program  office  for  action. 


e.  Other  Requirements  for  a  Proposal.  In  some  instances,  a  legitimate  requirement  for  a  proposal 
may  be  recognized  by  an  activity  (including  NOSC)  not  in  a  position  to  fund  the  necessary 
effort.  If  preparation  of  an  unsolicited  proposal  seems  appropriate,  procedures  should  follow 
those  described  in  the  case  of  an  informal  proposal  request. 
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Figure  4E-1.  Sequence  of  events  for  developing  a  proposal 


1.2.1  Bid  Decision  (Block  B) 


After  receipt  of  a  proposal  request,  the  preliminary  decision  to  bid  or  not  to  bid  the  proposed 
task  must  be  made.  This  decision  should  be  based  upon  whether  the  task  falls  within  the  NOSC  mission 
area  of  responsibility,  the  size  and  desirability  of  the  proposed  task,  the  availability  of  required  talent, 
facilities,  etc.,  and  must  be  in  consultation  with  all  divisions  or  departments  expected  to  play  a  major 
role.  The  decision  to  proceed  is  the  responsibility  of  the  cognizant  management  code.  Table  4E-1  provides 
a  rough  guide  to  the  level  of  review  expected. 


Obviously,  a  preliminary  “bid”  decision  may  be  reversed  during  subsequent  technical  review,  as  more 
data  become  available,  or  during  the  formal  management  review  required  prior  to  external  distribution 
of  the  proposal.  If  it  is  decided  that  no  bid  will  be  submitted,  the  cognizant  management  code  should 
prepare  a  letter  stating  the  reasons  for  not  bidding.  Whenever  possible  and  appropriate,  the  reply  should  jrtKfr, 
include  recommendations  for  an  alternate  development  agency,  contractor,  etc.  This  letter  should  be 
signed  out  using  the  same  guidelines  as  that  provided  for  bid  decisions. 

1.2.3  Detailed  Planning  for  Preparation  of  Proposals  (C  blocks) 

a.  The  proposal  task  manager,  working  with  others  as  appropriate,  should  complete  the  following 
detailed  planning  actions: 

(!)  Develop  an  outline  for  the  proposal.  Procedures  for  using  the  NOSC  Program  Summary 
format  and  for  the  NOSC  Alternate  Proposal  Format  have  been  previously  discussed. 

(2)  Verify  manpower  availability. 

(3)  Determine,  by  name,  contributors  to  each  section. 

(4)  Determine  schedule  for  completion  and  review. 

(5)  Determine  required  budget. 

(6)  If  necessary,  prepare  and  submit  request  for  funds  for  proposal  preparation,  etc., 
from  the  general  development  fund. 
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1.2.4  Preparation  and  Review  (D  blocks) 

a.  Prepare  draft  proposal  (include  initial  artwork).  Ensure  that  the  full  meaning  of  acronyms 
or  technical  abbreviations  and  nonstandard  terms  in  the  text  are  spelled  out  at  least  once. 

b.  Have  the  proposal  reviewed  internally  by  all  cognizant  NOSC  individuals. 

c.  If  desired  or  required,  have  the  proposal  reviewed  externally  before  completing  the  final  draft. 
If  this  course  of  action  is  taken,  clearly  mark  the  draft  proposal  as  “Working  Paper”  prior 
to  any  distribution  of  copies. 

d.  Incorporate  valid  review  comments  and  complete  final  cost  estimates,  typing,  and  artwork. 

e.  Obtain  an  final  review  from  cognizant  NOSC  codes.  Cognizant  codes  will  review  and  sign 
where  appropriate  on  I1ND-NOSC  5605/3.  When  more  than  one  program  office/division  is 
to  be  involved  in  the  proposed  task,  a  breakout  of  the  manpower  and  cost  estimate,  showing 
the  amounts  planned  for  each  participating  division,  must  be  included  on  the  form  11ND- 
NOSC  3920/9. 

1.2.5  Approval  of  a  Proposal  for  Distribution  (E  blocks) 

a.  For  those  proposals  requiring  department  head  review/approval,  as  set  forth  earlier,  cognizant 
department  head’s  signature  on  the  1 1ND-NOSC  3920/9  shall  certify  that  he/she  has  positively 
ensured  that  all  necessary  internal  agreements  have  been  negotiated  with  performing  division 
and  departments,  before  forwarding  the  proposal  to  the  originating  code. 

b.  For  proposals  requiring  review  and  approval  by  the  Technical  Director,  as  explained  earlier 
($  thresholds),  such  action  should  be  completed. 

c.  Upon  receipt  of  final  approval  of  the  proposal,  the  cognizant  code  is  authorized  to  prepare 
and  sign  the  letter  of  transmittal  that  initiates  the  external  distribution  of  the  proposal.  Where 
possible,  proposals  should  be  hand-delivered  to  sponsors.  If  submissions  are  intended  to  more 
than  one  potential  sponsor,  separately  addressed  copies  should  be  prepared  for  each.  Experience 
has  shown  that  “information”  addressees  are  prone  to  wait  and  see,  pending  a  final  decision 
by  the  “action”  addressee.  Hand-delivered  proposals  should  be  properly  cleared  through  the 
NOSC  mail  room  prior  to  delivery  to  ensure  that  an  official  record  of  transmittal  is  maintained. 

1.2.6  Reporting  Probability  of  Proposal  Acceptance  (H  blocks) 

If  not  previously  accomplished,  the  cognizant  management  code  should  ensure  that  the  estimated 
probability  of  acceptance  of  the  proposal  is  reported  to  the  branch,  division  and/or  department  head 
involved. 

1.2.7  Briefing  Material  (G  blocks) 

A  well-planned  briefing  presented  to  potential  sponsor(s)  concurrently  with  the  proposal  package 
usually  enhances  the  probability  that  the  proposed  task  will  be  funded.  Such  briefings  may  be  formal 
or  informal  but  should  be.carefully  tailored  to  the  anticipated  audience  and  circumstances.  Managers 
at  all  levels  are  urged  to  acquaint  themselves  with  the  variety  of  materials  available  as  briefing  aids, 
and  the  requirements,  capabilities,  and  limitations  of  various  briefing  techniques.  Preparation  of 
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appropriate  briefing  materials  should  begin  as  soon  as  proposal  details  are  sufficiently  well  known  to 
allow  time  for  adequate,  professional  standards  of  quality.  Normally,  such  briefings  should  be  reviewed 
at  the  level  of  the  supervisor  responsible  for  the  proposal  task,  prior  to  presentation  to  potential  sponsors. 
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SECTION  5 

STAFFING,  TEAM  BUILDING,  AND  COMMUNICATION 


5.1  INTRODUCTION 

5.1.1  References 

In  Search  of  Excellence 
The  One-Minute  Manager 
Negotiating  to  Yes 

How  to  Develop  Your  Executive  Ability 


5.2  STAFFING,  TEAM  BUILDING,  AND  COMMUNICATION 

What  do  we  mean  by  staffing,  team  building,  and  communication?  Briefly  stated  our  subjects 
can  be  brought  together  as  follows:  enough  people,  with  the  right  expertise  when  you  need  them,  working 
harmoniously  toward  a  common  set  of  goals  with  greatest  efficiency. 

In  the  following  pages  each  of  the  elements  of  our  topic  will  be  discussed.  In  staffing  (“enough 
people,  with  the  right  expertise  when  you  need  them. . .  ”)  you  are  looking  for  people  with  the  following 
characteristics: 

Motivated 

Educated 

Available 

Affordable 

Experienced 

High  priority  for  your  requirements 

In  team  building  (your  staff  “working  harmoniously  toward  a  common  set  of  goals. . .”)  it  is 
important  that  you  keep  the  following  ideals  in  mind: 

Goals  of  the  project  placed  above  self-interest 

Mutual  trust  and  respect 

Everyone  contributes 

And,  finally  in  communication  (your  staff  "working  harmoniously  . . .  with  greatest  efficiency”) 
open  communication  is  a  necessity;  this  open  communication  includes  listening  and  understanding, 
has  no  filters,  and  holds  no  untoward  surprises. 

You  program  managers  have  reason  for  optimism:  NOSC  hires  good  people  who  are  educated, 
motivated,  and  experienced.  Your  job  is  to  shape  them  into  a  team,  motivate  them,  and  lead  them. 
The  bottom  line  is  that  good  managers  have  good  people  working  for  them. 

What  is  the  secret  then  of  being  a  good  manager?  First,  it  is  hard  work  on  your  part.  Second, 
it  is  the  consistent  application  of  general  management  methods  that  work.  Third,  it  is  hard  work. 
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The  following  subsections,  though  still  brief,  discuss  staffing,  team  building,  and  communication 
in  more  detail. 


5.2.1  Staffing 


H 


Staffing,  in  most  instances,  is  the  easiest  part.  We  can  do  it  by  the  numbers,  acquiring  our  personnel 
from  coworkvi  -u  NOSC,  other  Navy  laboratories,  and  support  contractors.  There  is  a  real  need  to 
identify  your  tecnnical  expert  so  you  have  an  authoritative  viewpoint  early  in  your  program.  As  you 
build  your  staff  it  is  helpful  to  keep  in  mind  that  for  many  jods  inner  drive  and  motivation  are  more 
important  than  genius. 

It  is  also  impouant  that  you  do  not  forget  support  staff;  this  includes  the  Supply  and  Accounting 
staffs  here  at  NOSC,  already  in  place  to  help  implement  your  programs.  You  will  probably  find  that 
your  biggest  problems  are  not  technical.  Most  programs  experience  problems  related  to  contracting, 
and  “system”  constraints  probably  exceed  technological  problems.  This  might  be  related  to  the  fact 
that  in  the  Ubrary  of  Congress  here  are  1 , 1 52  lineal  feet  of  documents  governing  the  supply/acquisition 
process,  "t  ie  NOSC  Supply  and  Accounting  staffs  will  be  your  trailblazers  through  this  acquisition  jungle. 


5.2.2  Te»<tu  Building 


5.2.2.1  The  Basic  Rule.  Put  simply,  the  rule  says  do  not  mess  with  human  nature.  Human  nature 
r*  \lects  the  law  of  egocentrism:  each  person  is,  and  regards  himself  as,  the  center  of  his  own  world 
of  experience  and  action.  This  can  be  seen  in  the  way  people  see  themselves.  A  self-assessmer.t  performed 
by  a  random  sample  of  100  males  produced  the  following  results: 

a.  Ability  to  get  along  with  others 

All  100  ranked  themselves  in  the  top  50  percent  of  the  population 
60  percent  ranked  themselves  in  the  top  10  percent  of  the  population 
25  percent  ranked  themselves  in  top  1  percent  of  the  population 

b.  Leadership 

70  percent  rated  themselves  in  the  top  25  percent  of  the  population 
2  percent  felt  they  were  below  average  as  leaders 

c.  Athletic  ability 


60  percent  ranked  themselves  in  the  top  25  percent  of  the  population 
6  percent  indicated  they  were  below  average 


5.2.2. 2  Motivation.  It  is  best  recognize  what  human  nature  is  and  proceed  from  there.  Getting 
along  with  human  nature  requires  that  we  recognize  that  people  do  things  because  it’s  in  their  best 
interest  to  do  them.  Thus,  be  aware  of  the  following  motivating  factors: 


Self-fulfillment 

Anticipated  satisfaction  in  achievement 
Recognition  and  respect 
Opportunity  to  contribute 
Accountability  and  trust-expectations 


Interestingly,  pay  is  not  at  the  top  of  the  list. 
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Figures  5.1  through  5.5  present  the  Just  m  Time  (JIT)  MK46  production  line  case  history  that 
demonstrates  how  motivating  factors  can  be  applied  effectively. 

S.2.2.3  Decision  Making.  The  basic  practice  to  remember  here  is  do  not  make  all  the  decisions 
yourself.  If  you  feel  you  must  make  every  decision,  you  merely  limit  the  quality  of  your  program, 
ensure  that  nothing  happens  when  you  are  gone,  and  fail  to  build  the  sense  of  ownership  in  the  rest 
of  your  team.  As  you  allocate  decision  making  responsibilities  you  will  see  that  confidence  inspires 
confidence,  and  success  breeds  success.  The  program  will  be  the  winner. 

$.2.2.4  Modifying  Behavior.  Whenever  there  is  a  team  effort  there  is  bound  to  come  a  time  when, 
for  whatever  reasons,  some  term  member  is  performing  his  or  her  task  at  a  minimal  or  subminimal 
level.  You  as  program  manager  ;vill  need  to  and,  it  is  hoped,  want  to  address  this  problem.  The  first 
step,  often  forgotten,  is  to  praise  good  work  and  behavior.  Secondly,  in  contrast  to  the  counsel  of 
The  One-Minute  Manage,  use  criticism  sparingly.  If  you  must  criticize,  never  criticize  a  team  member 
in  front  of  others  nor  in  an  emotional  outburst.  Also  focus  on  criticizing  the  act,  not  the  individual. 
Explore  ways  of  saying  wbiu  needs  to  be  said;  for  instance,  the  use  of  the  phrase  “Are  you  aware. . .  ?” 
can  provide  a  reasonably  comfortable  transition  into  discussing  a  possible  area  of  trouble. 

5.2.2.5  Conflict  Management.  There  is  another  inevitability  when  two  or  more  human  beings  are 
working  together  for  any  length  of  time.  There  will  be  some  conflict.  The  law  of  egocentrism  is  still 
at  work.  The  following  are  some  useful  preliminary  steps  to  managing  conflicts: 

Get  the  facts 

Separate  the  emotion  from  the  problem 
Listen  to  understand 
Look  for  points  of  agreement 
Look  for  graceful  ways  out 

It  would  be  very  useful  to  familiarize  yourself  with  the  negotiating  approaches  presented  in  Table 
5.J  and  practice  them  as  you  have  opportunity. 

5.2.2.6  The  Basic  Rule  and  You.  Remember  that  the  law  of  egocentrism  applies  to  you  too.  Thus, 
it  is  in  your  best  interest  to  develop  a  strong  team.  Finally,  recognize  that  the  same  factors  that  motivate 
you  motivate  your  team  as  well.  The  particulars  may  be  different,  but  the  principles  remain  the  same. 


5.2.3  Communication 

Whenever  you  have  a  group  of  people  working  together  there  will  be  communication.  The  question 
is,  however,  will  it  be  good  communication  or  poor  communication?  This  is  the  choice.  Will  we  have 
open,  straightforward,  two-way  communication?  Or  will  we  have  limited,  one-way  communication 
fueled  by  rumor? 

We  know  that  good  communication  is  required  for  effective  team  building  and  project  efficiency 
and  that  the  lack  of  good  communication  leads  to  poor  efficiency.  People  worry  if  they  think  there 
is  something  that  will  affect  them  that  they  do  not  know.  They  worry  about  their  own  self-interests, 
and  worry  is  more  likely  to  be  caused  by  rumor  than  fact.  There  can  even  be  a  geographical  or  location 
component  to  the  communication;  Figure  5.6  was  taken  from  In  Search  of  Excellence.  Good 
communication  takes  work. 
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Figure  5.2.  Process  flow  diagram. 


FINAL  ASSEMBLY  -  FIRE  CONTROL 
(AFTER  JIT) 


Figure  5.4.  MK  46  quality  trends. 
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Table  S.l.  Negotiating  approaches. 


Problem 

Positional  bargaining:  Which  game  should  you  play? 


Solution 

Change  the  Game  — 
Negotiate  on  the  Merits 


SOFT 

Participants  are  friends 

The  goal  is  agreement 

Make  concessions  to 
cultivate  the  relationship 

Be  soft  on  the  people  and 
the  problem 

Trust  others 

Change  your  position  early 

Make  offers 

Disclose  your  bottom  line 

Accept  one-sided  losses  to 
reach  agreement 

Search  for  the  single  answer: 
the  one  they  will  accept 

Insist  on  agreement 

Try  to  avoid  a  contest  of 
will 

Yield  to  pressure 


HARD 

Participants  are  adversaries 

The  goal  is  victory 

Demand  concessions  as  a 
condition  of  the 
relationship 

Be  hard  on  the  problem  and 
the  people 

Distrust  others 

Dig  in  to  your  position 

Make  threats 

Mislead  as  to  your  bottom 
line 

Demand  one-sided  gains  as 
the  pri;  '*  of  agreement 

Search  for  the  single  answer: 
the  one  you  will  accept 

Insist  on  your  position 

Try  to  win  a  contest  of  will 

Apply  pressure 


PRINCIPLED 

Participants  are  problem- 
solvers 

The  goal  is  a  wise  outcome 
reached  efficiently  and 
amicably 

Separate  the  people  from  the 
problem 

Be  soft  on  the  people,  hard 
on  the  problem 

Proceed  independent  of  trust 

Focus  on  interests,  not 
positions 

Explore  interests 

Avoid  having  a  bottom  line 

Invent  options  for  mutual 
gain 

Develop  multiple  options  to 
choose  from;  decide  later 

Insist  on  using  objective 
criteria 

Try  to  reach  a  result  based 
on  standards  independent 
of  will 

Reason  and  be  open  to 
reason;  yield  to  principle, 
not  pressure 


Good  program  communication  can  be  promoted  through  implementing  the  following  approaches: 
Regular  meetings 

Management  by  walking  around  (not  announced,  scheduled  tours) 

Tell  them  more  than  they  need  to  know,  let  them  filter  for  themselves 
Listen,  consider,  evaluate,  discuss 
Remember  to  cooperate  with  human  nature 

Do  not  shoot  the  messenger  (value  the  person  who  tells  you  hard  truths) 


S3  IMPLEMENTATION/EXECUTION 

The  bottom  line  is  that  management  techniques  are  relatively  simple  to  delineate  and  learn.  The 
key  then  to  good  program  management  is  importation  and  execution. 

The  authors  of  In  Search  of  Excellence  (Chapter  1),  in  reviewing  studies  of  62  successful  companies, 
found  many  similarities  among  them.  These  companies  exhibited  the  following  characteristics  from 
1961  through  1980: 

Compound  asset  growth 

Compound  equity  growth 

Highest  average  ratio  of  market  value  to  book  value 

Highest  average  return  on  capital 

Highest  average  return  on  equity 

Highest  return  on  sales. 

Table  5.2  presents  the  eight  common  basic  principles  identified  as  the  attributes  that  “characterize 
most  nearly  the  distinction  of  the  excellent,  innovative  companies.” 

A  final  word.  The  principles  governing  staffing,  team  building,  and  communication  are  well  known. 
It  is  your  task  to  work  at  implementing  them  for  your  program  and  learning  how  they  work  in  the 
real  world.  Then  you  can  also  model  them  and  teach  them  to  your  coworkers. 


T*bl«  5.2.  Principles  of  excellence  and  innovation. 


Principle 
1.  A  Bias  for  Action 


2.  Stay  Close  to  the  Customer 


3.  Autonomy  and 
Entrepreneurship 


4.  Productivity  through  People 


5.  Hands-on,  Value  Driven 


6.  Stick  to  the  Knitting 

7.  Simple  Form,  Lean 
Administrative  Staff 

8.  Simultaneous  Loose-Tight 
Properties 


Comments 


Break  the  problem  into  parts  (chunking) 

Use  small  Ad  Hoc  task  forces  with  limited  life,  (specific 
assignment  for  a  short  period  of  time) 

“Do  it,  fix  it,  try  it”  —  characterizes  experimenting 
organizations 
Simplify 

Chaotic  actions  are  better  than  inaction 
Ready,  fire,  aim,  learn 

Figure  out  what  he  needs 

Provide  it 

Quality 

Nichemanship 

Listen  to  the  user 

Break  the  corporation  into  small  companies 
Encourage  them  to  think  independently  and  competitively 
Support  innovation 
Communicate 

“The  new  idea  either  finds  a  champion  or  dies...” 
Edward  Schon,  MIT 

Create  an  awareness  that  their  best  efforts  are  essential 
Success  will  be  recognized 
Focus  on  people  —  build  a  team 

Managers  keep  in  touch 
A  belief  in  being  the  “best” 

A  belief  in  the  details  of  execution 
A  belief  in  the  importance  of  people 
A  belief  in  superior  quality  and  service 
Practice  management  by  walking  around 

Build  diversification  strategies  on  some  central  skill  or  strength 

Minimum  staff  at  the  corporate  level 
Subunits  should  have  their  own  staff  support  (supply, 
personnel,  finance) 

Simple  organizations  —  accountability  and  autonomy 

Coexistence  of  firm  central  direction  and  maximum  individual 
autonon./,  entrepreneurship,  and  innovation 
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SECTION  6 

MAJOR  SYSTEMS  ACQUISITION 


6.1  INTRODUCTION 

6.1.1  References 

“Project  Management:  An  Overview,”  James  J.  O’Brien,  Project  Management  Quarterly ,  Volume 
VIII,  Number  3,  September  1977.  SCAN. 


6.2  THE  WORLD  OF  PROGRAM  MANAGEMENT 


6.2.1  The  Role  of  the  Program  Manager 

A  fundamental  Department  of  Defense  (DoD)  policy  is  that  the  acquisition  of  major  weapon  systems 
will  be  directed  by  responsible  managers  under  the  concept  of  program  management. 

The  concept  of  program  management  is  to  provide  centralized  management  authority  over  all  of 
the  technical  and  business  aspects  of  a  program.  The  program  manager’s  role,  then,  is  to  tie  together, 
to  manage,  and  to  direct  the  development  and  production  of  a  system  meeting  performance,  schedule, 
and  cost  objectives  which  are  defined  by  his/her  Service  and  approved  by  the  Secretary  of  Defense 
(SECDEF).  The  essence  of  the  program  manager’s  role  is  to  be  the  agent  of  the  Service  in  the  management 
of  the  system  acquisition  process  and  to  focus  the  authority  and  responsibility  of  the  Service  for  running 
the  program.  Program  managers  have  the  vantage  of  a  large  perspective  of  the  program  and  the 
interrelationships  among  its  elements.  Program  managers  must  be  the  major  motive  force  for  propelling 
the  system  from  conception  to  completion. 

Recently,  a  panel  of  military  program  managers  examining  their  role  likened  it  to  that  of  the  general 
manager  of  a  small  company.  The  comparison  is  especially  apt.  It  would  be  impossible  to  write  a 
meaningful  position  description  for  that  job.  It  is  equally  impossible  to  write  one  for  the  program 
manager’s  job.  What  the  general  manager  does  is  whatever  is  needed  to  move  the  affairs  of  the  business. 
The  general  manager  does  one  thing  at  one  time  and  another  thing  at  another  time— whatever  is  most 
needed  at  the  moment  to  achieve  the  objectives.  A  general  manager  is  not  a  “doer”  of  any  job— there 
are  other  managers  charged  with  the  doing.  But  general  managers  see  to  it  that  what  they  want  is  done, 
and  what  they  want  is  a  harmony  of  things  done  so  that  their  objectives  are  achieved.  The  role  implies 
reliance  on  others  to  do  the  work;  but  it  also  implies  controlling  and  coordinating  the  work  so  that 
no  one  aspect  dominates  others  to  the  detriment  of  the  harmony  of  the  whole. 

This  touches  upon  what  is  likely  to  be  the  most  important  function  of  the  program  manager:  getting 
people  to  communicate  with  each  other  to  achieve  a  common  understanding  of  the  needs  of  the  program 
and  their  place  in  the  harmony  of  the  total  program  effort. 
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6.2.2  Service  Responsibility 

It  is  an  oversimplification,  but  basically  correct,  to  identify  three  players  and  their  respective  roles: 
the  Service,  the  program  manager,  and  the  Office  of  the  Secretary  of  Defense  (OSD).  The  Service  is 
responsible  for  identifying  its  operational  needs  and  defining  the  new  systems  required  to  meet  those 
needs.  It  is  also  responsible  for  the  formulation  of  the  acquisition  strategy  for  the  orderly  development 
and  production  of  the  systems.  The  program  manager  is  the  agent  of  the  Service  for  the  formulation 
and  execution  of  the  strategy.  OSD  is  the  keeper  of  the  Service  conscience — it  reviews  and  approves 
the  Service  strategy  and  program.  But  the  center  of  systems  acquisition,  authority,  and  responsibility 
lies  in  the  Service— more  specifically,  it  is  the  Service  Secretary. 

Approval  improperly  exercised  means  direction  in  practice.  It  is  possible  to  withhold  approval 
until  the  one  approach  desired  by  the  approving  authority  is  reluctantly  proposed  (or  stumbled  upon) 
by  the  organization  or  person  seeking  the  approval.  That  way  of  exercising  approval  is  directing — 
albeit  obliquely.  He/she  who  exercises  “approval”  power  in  that  mode  is  seen  to  have  assumed  the 
role  of  directing,  while  perhaps  planning  to  dodge  responsibility  if  things  go  wrong. 

However,  the  role  of  line  and  staff  authority  has  been  delineated  in  the  DoD  Directive 
5000.1-  “Major  System  Acquisitions”  dated  18  January  1977. 

WIv;n  a  line  official  above  the  program  manager  exercises  decision  authority  on  program  matters, 
the  decision  shall  be  documented  as  official  program  direction  to  the  program  manager.  The  line 
official  shall  be  held  accountable  for  the  decision.  The  role  of  staffs  as  functional  advisors  does 
not  include  the  authority,  responsibility  or  accountability  for  program  decisions.* 

Approval  means  something  else,  especially  in  the  context  of  OSD’s  role  in  military  program 
management.  It  denotes  a  dictionary  definition  of  the  word  “approval”:  “to  accept  as  satisfactory.” 
That  is  to  say,  it  is  the  Service’s  role  to  formulate  the  system  requirements  and  plan  for  implementation. 
It  is  OSD’s  role  to  accept  the  Service’s  product  as  satisfactory— provided  it  is  consistent  with  major 
policy  objectives.  It  is  also  OSD’s  role  to  evaluate  the  performance  of  the  Services  in  implementating 
the  approved  programs.  But  the  Service  has  the  final  responsibility  for  getting  the  job  done. 


6.2.3  Judgment  and  Flexibility 
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The  concept  of  program  management  came  about  because  the  ordinary  way  of  doing  things  was 
not  adequate  for  the  task  of  managing  the  acquisition  of  complex  weapon  systems.  Extraordinary 
management— program-oriented  management— was  essential  if  all  of  the  aspects  of  the  program  were 
to  be  handled  correctly  and  expeditiously. 

To  achieve  this  extraordinary  management,  there  is  another  OSD  policy  which  complements  the 
policy  requiring  program  management:  military  program  managers  should  be  free  to  exercise  judgment 
and  flexibility.  Although  program  managers  are  the  agents  of  the  Service,  they  should  operate  in  an 
environment  in  which  they  select  and  tailor  to  the  specific  needs  of  their  program  those  management 
systems  and  formal  techniques  that  will  help  the  program.  Program  managers  should  operate  in  an 
environment  conducive  to  the  exercise  of  judgment.  There  is  no  pet  formula  program  managers  can 
adopt.  They  must  decide  for  themselves  what  methods,  techniques,  and  systems  to  use.  If  program 
managers  are  responsible  for  planning,  directing,  and  controlling  a  piogram,  they  must  have  the  authority 
to  get  the  job  done. 


*Dept  of  Defense,  “Major  System  Acquisitions,”  Directive  5000.1,  18  January  1977,  p  6. 
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Stated  another  way,  the  program  manager  is  encouraged  to  adapt  standard  techniques  to  the  peculiar 
requirements  of  the  program.  In  turn,  program  managers  have  a  right  to  expect  that  those  in  the  Services 
who  are  going  to  approve  management  plans  and  techniques  will  exercise  their  power  of  approval 
properly.  That  is  to  say,  plans  and  techniques  will  be  accepted  as  satisfactory  if  they  comply  with  basic 
policy  directives.  Program  managers  have  a  right  to  expect  that  their  plans  will  not  be  judged  by  the 
standard  of  meticulous  compliance  with  innumerable  details  hidden  away  in  regulations,  directives, 
instructions,  handbooks,  manuals,  standards,  specifications,  or  similar  documents. 

What  program  managers  have  a  right  to  expect  and  what  in  fact  they  will  be  offered  are  often 
quite  different.  Experienced  program  managers  would  remind  the  new  program  manager  that  often 
one  must  struggle  to  obtain  the  management  flexibility  he/she  is  supposed  to  be  given.  Higher  authorities, 
and  especially  their  staff  organizations,  tend  to  standardize  their  requirements  and  to  insist  on  the  use 
of  familiar  techniques  and  methods.  Their  initial  disposition  is  to  avoid  changes  and  exceptions  to  the 
general  rule.  Requests  for  deviations  are  rarely  conceded  without  being  pushed  and  sola. 

6.2.4  Functional  Support 

The  use  of  judgment  and  the  exercise  of  flexibility  are  difficult  to  achieve  in  the  environment  of 
military  program  management.  The  most  significant  reason  for  this  is  that  the  operation  of  program 
management  envisions  two  organizational  elements.  In  some  few  cases  the  program  office  is  staffed 
with  all  or  most  of  the  capability  to  perform  the  functional  activities.  In  these  cases  the  program  office 
is  largely  self-sufficient  and  does  not  have  to  rely  on  much  support  from  functional  activities  outside 
of  the  line  authority  of  the  program  manager.  Coordination  is  simplified,  but  the  problems  associated 
with  organizing  and  staffing  the  program  office  are  magnified.  Usually,  however,  there  is  a  small, 
centralized  management  authority  consisting  of  the  program  manager  and  his/her  program  office.  This 
office  is  served  by  functional  organizations  which  support  the  centralized  authority  and  which  are 
responsible  to  it  for  the  execution  of  assigned  tasks.  This  environment,  where  the  resources  for  doing 
the  work  are  largely  outside  of  the  line  authority  of  the  program  manager,  is  a  natural  source  of  conflict. 

The  practical  fact  is  that  there  are  usually  several  programs  competing  for  the  limited  resources 
of  the  same  functional  organizations.  Those  functional  elements  are  also  supporting  the  normal  activities 
of  their  parent  organizations— the  day-to-day,  nonprogram  activities.  When  personnel  are  not  available 
to  support  all  of  the  demands,  program  managers  find  less  responsiveness  than  they  desire  from  the 
functional  elements.  Tr.e  situation  is  made  even  more  difficult  because  the  functional  elements  were 
there  long  before  the  program  started  and  they  plan  to  be  there  long  after  the  program  ends. 

Another  aspect  of  this  problem  is  the  tendency  of  functional  specialists  to  see  their  discipline  as 
the  central  core  of  a  successful  program.  Their  commitment  to  their  specialty  leads  them  to  try  to  dictate 
to  the  program  what  will  or  must  be  done— as  distinguished  from  advising  what  should  be  done.  Further, 
there  is  no  lack  of  regulations  with  which  they  can  bolster  their  claim.  One  of  the  most  difficult  concepts 
to  put  across  to  functional  specialists  is  that  the  program  manager  is  responsible  for  determining  what 
will  be  done.  The  functional  specialist  is  responsible  for  how  it  is  done— the  how  being  his  area  of 
expertise. 

There  is  a  natural  tendency  for  the  functional  managers  to  standardize  their  operations  or 
efforts,  to  perform  to  standards,  or  to  build  a  standard  model.  A  program  manager  must,  through 
influence,  force  functional  areas  to  depart  from  a  standard  and  build  something  that  fits  in  with 
the  other  parts  of  the  project.  Someone  has  to  force  these  people  to  take  action  when  these  actions 
increase  a  functional  manager’s  risk  or  use  resources  at  a  greater  rate  than  expected.  The  program 
manager’s  role  is  to  balance  this  risk  over  all  portions  of  the  project.  Therefore,  the  program  manager 
must  have  authority  to  move  quickly  to  balance  risk.* 


•George  A.  Steiner  and  William  G.  Ryan,  Industrial  Project  Management,  the  Macmillan  Company,  1968,  p  29. 
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The  obverse  is  equally  true,  however.  Once  the  government  program  manager  has  obtained 
the  necessary  assurance,  he/she  should  relax  control  and  concede  to  contractors  a  measure  of 
freedom  to  exercise  judgment  and  flexibility. 

Problems  with  functional  specialists  are  not  something  new: 


The  expert,  in  fact,  simply  by  reason  of  his  immersion  in  a  routine,  tends  to  lack  *.• 
of  mind  once  he  approaches  the  margins  of  his  special  theme.  He  is  incapable  of  rapid 
adaptation  to  novel  situation* .  He  unduly  discounts  experience  which  does  not  tally  with  his 
own.  He  is  hostile  to  views  which  are  not  set  out  in  terms  he  has  been  accustomed  to  handle. 
No  man  is  so  adept  at  realizing  difficulties  within  the  Held  that  he  knows;  but,  also,  few  are 
so  incapable  of  meeting  situations  outside  that  field.  Specialism  seems  to  breed  a  horror  of 
unwonted  experiment,  a  weakness  in  achieving  adaptability,  both  of  which  make  the  expert 
of  dubious  value  when  he  is  in  supreme  command  of  a  situation.* 


The  environment  of  program  management  therefore  places  an  extraordinary  premium  on  talent 
for  leadership  as  distinguished  from  command,  on  persuasion  as  distinguished  from  direction.  The 
environment  requires  an  emphasis  on  informal  authority,  de  facto  authority,  or  influence  as  distinct 
from  power.  One  student  of  program  management  has  described  this  authority  as  derived  in  part  from 
the  program  manager’s  “persuasive  ability,  his  rapport  with  extraorganizational  units,  and  his  reputation 
in  resolving  opposing  viewpoints  within  the  parent  unit  and  between  the  external  organizations.”** 


Persuasion  is  not  the  only  way  to  get  things  done.  One  defense  program  manager  said  that  on 
many  occasions  he  overcame  the  opposition  of  functional  specialists  by  “working  harder  than  they 
did.”  This  program  manager  found  that  he  could  so  overwhelm  a  specialist  with  facts,  figures,  and 
analysis  that  it  became  too  much  of  an  effort  for  the  specialist  to  refute  the  program  manager’s  position. 


The  comments  of  this  program  manager  highlighted  a  point  made  by  several  others  that  there 
is  a  need  for  a  strong  analytical  capability  in  the  program  office  to  coordinate  a  program  whose  parts 
were  organizationally  and  geographically  widely  dispersed.  A  talent  for  analysis  and  ability  to  work 
with  people  were  the  key  criteria  in  their  selection  of  program  office  personnel. 


6.2.S  Engagement  and  Disengagement 


In  common  with  the  way  a  general  manager  must  operate,  the  program  manager  relies  on  others 
to  do  the  work.  But  program  managers  cannot  escape  the  responsibility  for  the  result.  If  they  are 
responsible,  they  must  be  satisfied  that  what  is  done  in  the  program  makes  sense  and  is  consistent  with 
their  plans.  If  program  managers  cannot  be  persuaded  that  it  is  right  for  their  program,  they  must 
direct  it  to  be  done  the  way  they  want. 

Much  has  been  written  about  the  role  of  industry  and  the  relationship  that  should  obtain  between 
the  defense  program  manager  and  the  industry  counterpart.  Much  has  been  said  about  “disen¬ 
gagement”— getting  out  of  industry’s  hair  and  letting  them  do  the  job  they  have  contracted  to  do. 
The  goal  is  laudable  and,  the  way  it  is  stated,  the  idea  is  entirely  consistent  with  good  management 
concepts.  But  the  ultimate  responsibility  for  a  successful  program  rests  squarely  on  the  Service  and 
on  the  military  program  manager  as  its  agent.  Program  managers  cannot  disengage  in  any  literal  sense. 
They  must  manage  contracted  work  in  just  the  same  sense  as  they  manage  all  the  other  parts  of  the 
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•  Harold  j.  Laski,  "The  Limitations  of  the  Expert,”  Harper’s  Magazine,  December  1930.  Quoted  in  Specialists  and  Gener¬ 
alists,  a  selection  of  readings  by  the  Committee  on  Government  Operations,  U.S.  Senate,  90th  Congress,  2d  Session,  1968,  p  53. 

**  David  1.  Cleland,  “Project  Management,”  Air-University  Review,  Voi.  XVI,  No.  2,  January-February,  1965.  Reprinted 
in  a  book  of  readings  compiled  by  David  I.  Cleland  and  William  R.  King,  Systems,  Organizations,  Analysis,  Management, 
McGraw>Hill  Book  Company,  1969. 
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program.  More  precisely,  in  this  case  they  manage  contractor  management  of  their  program.  It  is  not 
a  question  of  whether  they  manage;  it  is  only  a  question  of  how  they  manage— or  mismanage. 

Industry  program  managers  and  government  program  managers  are  agreed  on  this  point: 

It  seems  clear  that  the  Government  program  manager  must  exercise  rather  tight  control  until 
such  time  as  he  is  assured  that  the  industrial  project  manager  has  the  technical  and  managerial 
competence  to  perform  as  required.* 


6.2.6  The  Soft  Sell 

Newly  appointed  program  managers  may  be  dismayed  to  discover  that  there  is  less  than  complete 
and  enthusiastic  support  for  their  programs  within  their  Service  and  OSD.  Every  weapon  system  competes 
with  all  the  others  for  limited  resources,  and  competition  is  especially  fierce  in  periods  of  tight  budgets. 
At  every  level  in  the  hierarchy,  commanders  and  staff  personnel  are  confronted  by  demands  from  program 
and  functional  managers  for  far  more  money  than  is  available  or  can  reasonably  be  obtained.  Budget 
recommendations  and  decisions  must  be  made  that  will  inevitably  favor  some  programs  over  others. 


Program  managers  who  have  done  their  homewor and  have  kept  key  people  informed  about  their  ] 

system’s  programs  and  progress  will  improve  the  odds  that  funds  for  their  program  will  not  be  reduced.  r  i 

We  are  not  suggesting  that  program  managers  affect  a  hard-sell  stance  or  that  they  patrol  corridors  r< 

to  buttonhole  unwary  staff  people.  What  we  are  suggesting  is  that  a  program  manager  should  be  attuned  I 

to  the  information  needs  and  biases  of  the  people  who  influence  budget  decisions.  This  implies  a  kind  t 

of  low-key  salesmanship— of  the  soft-sell,  helpful  variety.  \ 


One  of  the  program  manager’s  greatest  sources  of  authority  involves  the  manner  in  which 
he  builds  alliances  in  his  environment— with  his  peers,  associates,  superiors,  subordinates,  and 
other  interested  parties.  The  building  of  alliances  supplements  his  legal  authority;  it  is  the  process 
through  which  the  project  manager  can  translate  disagreement  and  conflict  into  authority  (or 
influence  p.»wer)  to  make  his  decisions  stand.  Sometimes  the  power  and  control  of  the  project 
manager  represents  a  subtle  departure  from  his  legal  authority.* 

Program  managers  must  keep  in  touch  with  what  is  going  on  above  them.  They  have  to  be  aware 
of  what  is  expected  by  higher  authority— both  in  their  Service  and  at  the  OSD  level.  They  should  know 
the  typical  questions  being  asked  at  major  program  review  points,  and  they  should  be  aware  that  these 
requirements  for  information  by  higher  authority  are  constantly  changing. 

Program  managers  speak  at  length  on  the  need  to  instill  confidence  in  superiors.  This  confidence 
is  a  foundation  of  rapport  with  superiors  which,  in  turn,  is  one  of  the  main  sources  of  the  program 
manager’s  authority.  When  it  is  obvious  to  functional  managers  supporting  the  program  that  the  program 
managers  have  this  rapport  with  their  superiors,  they  will  not  need  to  rely  as  much  on  formal  authority. 
One  of  the  ways  this  confidence  can  be  instilled  is  by  demonstrating  a  knowledge  of  the  program  in 
the  widest  context.  Knowledge  of  the  program  must  embrace  the  threat,  the  direction  in  which  the 
threat  is  moving,  other  systems  in  the  inventory  that  address  the  threat,  program  schedules,  costs, 
technology— in  short,  everything  important  about  the  program. 


•Steiner  and  Ryan,  op.  tit.,  p  125. 
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6.3  DEFENSE  COMMUNIQUE  ON  DEFENSE  ACQUISITION  MANAGEMENT 


(The  statement  by  Dr.  Richard  D.  Delauer,  Under  Secretary  of  Defense  for  Research  and  Engineering 
before  the  Senate  Armed  Services  Committee,  November  16, 1983  on  Defense  Acquisition  Management 
offers  valuable  guidelines.) 


6.3.1  Management  Philosophy 

Our  approach  to  management  is  one  in  which  *e  strive  for  a  proper  balance  between  policy 
formulation  and  resource  allocation  on  one  hand,  and  decentralized  program  execution  on  the  other. 
In  order  for  this  concept  to  be  effective,  it  is  imperative  to  have  the  necessary  management  oversight 
to  ensure  that  policies  and  plans  are  being  implemented.  Since  the  Carlucci  initiatives  were  adopted 
over  two  years  ago,  the  Department  has  made  great  progress  in  implementing  this  philosophy.  Within 
the  Department  we  have  made  significant  progress  toward  implementing  a  more  efficient  and  effective 
management  focus 

Before  I  describe  the  major  organizations  and  offices  which  are  involved  in  managing  the  acquisition 
process  within  the  Department,  let  me  outline  briefly  the  process.  Our  defense  requirements  are  established 
each  year  by  the  Secretary  in  cooperation  with  the  Services  and  the  Joint  Chiefs  [of  Staff  (JCS)]  through 
defense  guidance.  The  Services  submit  a  5-year  plan  called  the  Program  Objective  Memorandum  (POM) 
to  the  Secretary  based  upon  defense  guidance.  The  Service  plans  are  analyzed  ior  completeness  and 
consistency  with  our  basic  policies.  Any  inconsistencies  result  in  issues  which  are  brought  before  the 
Defense  Resources  Board  (DRB). 

The  DRB,  chaired  by  the  Deputy  Secretary,  is  the  major  decisionmaking  body  in  the  Department’s 
resource  allocation  process.  Participative  management  governs  the  Board’s  activities  since  high-level 
representatives  from  all  major  DoD  components,  including  the  Service  secretaries  and  JCS  participate 
in  DRB  decisions.  The  focus  of  DRB  attention,  however,  is  upon  issues  where  resources  do  not  fulfill 
policy  objectives. 

During  this  year’s  program  review,  issues  settled  by  the  DRB  accounted  for  about  3  percent  of 
the  total  funding  requests  submitted  in  this  year’s  POM.  Moreover,  this  small  proportion  represented 
only  issues  of  highest  priority  where  the  DRB  decided  that  the  initially  proposed  resource  were  not 
appropriate  for  the  required  task. 

As  a  partner  in  defense  acquisition  management,  Congress  shares  the  responsibility  to  participate 
in  policy  formulation  and  implementation  oversight.  However,  it  seems  that  over  the  years,  Congress 
has  digressed  from  an  oversight  role  in  which  it  would  participate  in  the  establishment  of  policy  objectives 
and  measure  progress  toward  achieving  the  policy  go.  ’s.  Unfortunately,  congressional  oversight  has 
become  far  too  detailed  to  provide  policy  makers  or  the  public  with  a  coherent  view  of  our 
accomplishments  or  our  needs.  The  solution  to  this  problem  comes  down  to  asking  the  right  questions, 
receiving  the  appropriate  information,  and  intervening  only  when  things  go  off  track. 

For  example,  we  should  be  asking  questions  about  our  objectives  on  the  basis  of  mission  areas. 
“Where  are  we  going,”  we  should  ask,  “in  strategic  forces;  air,  sea,  and  land  mobility;  conventional 
forces,  etc.?”  We  have  worked  this  problem  pretty  well  in  the  areas  of  strategic  offensive  forces  and 
in  air  mobility  for  example.  We  haven’t  yet  done  well  at  all,  however,  in  sea  and  land  mobility  or 
in  the  general  area  of  conventional  forces. 

We  have  observed,  however,  congressional  oversight  in  practice  has  become  more  of  an  annual 
exercise  in  line-item  management.  Due  to  the  parochial  interests  of  constituencies  and  the  increase  in 
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size  and  diversity  of  congressional  staffs,  every  year  we  must  assume  a  “prevent  defense”  on  a 
programmatic  basis.  What  is  needed  is  increased  awareness  of  our  mission  goals  and  our  progress  toward 
their  achievement— not  whether  this  or  that  program  needs  to  be  adjusted. 

The  information  which  is  provided  to  Congress  needs  to  reflect  the  oversight  function  which  I 
have  described.  For  example,  the  Selected  Acquisition  Reports  (SARs)  to  Congress  need  some  J 

modification  in  order  to  be  more  meaningful  for  effective  oversight.  First,  I  believe  SARs  should  be 
based  on  a  5-year  planning  period  rather  than  for  the  total  program  inventory  objective  as  is  presently 
the  case.  The  problem  is  that  adjustments  to  these  outyear  inventory  objectives  change  program  costs. 

The  result  looks  like  poor  management  rather  than  a  reflection  of  the  uncertainties  of  these  outyear 
projections.  To  make  valid  estimates  of  the  inventory  objectives  of  our  major  systems  beyond  a  5-year  j 

period  and  have  them  be  meaningful  is  almost  impossible.  We  recognize  the  need  to  have  planning 
figures  for  the  total  program,  but  the  uncertainty  in  these  numbers  must  also  be  acknowledged. 

In  addition,  congressional  oversight  should  be  practiced  on  a  “by-exception”  basis  where  only 
the  major  problems  are  addressed.  Recent  changes  brought  about  by  the  Nunn-McCurdy  Act  have  ! 

increased  the  reporting  requirement  for  major  systems  by  almost  50  percent.  This  additional  requirement 
necessitates  thousands  of  additional  hours  of  preparation  and  review  for  a  variety  of  systems,  many 
of  which  are  not  sufficiently  mature  to  establish  a  meaningful  baseline.  Moreover,  the  programmatic 
structure  of  the  SAR  reinforces  the  line  item  management  mentality  of  which  I  have  already  spoken. 

I 

Everyone  agrees  that  what  is  needed  most  of  all  in  the  acquisition  process  is  greater  stability.  Yet,  | 

each  year  we  observe  that  hundreds  of  programs  are  adjusted  by  the  Congress  in  accordance  with  \ 

undefined  priorities.  The  following  year,  we  must  return  to  Congress  to  attempt  to  get  essential  programs  2 

back  on  track.  As  a  result  of  our  adjustment  and  other  inefficiencies,  it  now  takes  from  12  to  17  years  j 

to  complete  the  acquisition  process  for  most  major  items.  If  we  could  simply  recognize  the  instability  J 

which  we  introduce  into  the  acquisition  process  and  the  consequent  cost  (both  in  dollars  and  national 
security),  we  will  have  achieved  a  major  step  forward.  We  are  improving  stability  through  many  of  I 

our  initiatives  such  as  multiyear  procurement,  economic  production  rates,  and  realistic  budgeting. 

However,  much  more  needs  to  be  done.  I  strongly  endorse  the  Secretary’s  recommendation,  for  example,  | 

that  the  Congress  adopt  a  2-year  budget  cycle  to  help  alleviate  the  instability  problem.  I  believe  it  would  > 

reduce  the  average  time  needed  for  completion  of  the  acquisition  process,  and  would  also  mean  signifi¬ 
cant  cost  savings  in  the  long  run.  I 

! 

6.3.2  Funding  Distinctions 


Another  contributing  factor  to  inefficient  management  which  constrains  the  acquisition  process 
is  the  artifical  distinction  which  is  made  among  vai  ious  types  of  funding.  The  acquisition  process  embraces  \ 

exploratory  research,  engineering  development,  manufacturing  assembly,  and  deployment.  To  assume  J 

that  these  phases  can  be  defined  and  funded  in  a  rigid  manner  (RDT&E  and  production)  is  nonsense.  j 

It  is  artificial  and  expensive.  Resources  should  be  applied  as  is  necessary  to  do  the  job  in  the  most  j 

efficient  way.  Line  managers  who  are  close  to  the  prog,  am  should  retain  the  flexibility  to  make  these  \ 

judgments  and  act  accordingly.  If  we  could  remove  this  artificial  distinction  in  characterizing  funds,  I 

I  believe  we  could  save  money  and  shorten  the  process  as  much  as  10  to  20  percent.  n 

We  are  now  trying  to  add  more  emphasis  to  the  critical  transition  period  from  R&D  to  | 

manufacturing.  We  are  establishing  a  new  DoD  directive  to  enhance  our  attention  to  this  problem,  | 

and  I  am  looking  at  ways  to  strengthen  the  production  and  manufacturing  areas  within  DoD.  I  think  jj 

v/e  need  to  beef-up  the  R&E  (research  and  engineering)  organization  in  this  area.  We  may  well  need  I 

additional  manpower  spaces  to  devote  to  this  problem.  j 
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Another  subject  which  causes  us  great  concern  is  the  present  definition  of  competitive  procurement. 
The  way  we  keep  score  is  very  misleading  to  the  uninitiated  and  we  need  to  redefine  the  terms.  Practically 
all  of  our  programs  are  initially  competitive,  and  we  examine  the  acquisition  strategy  in  great  detail 
to  seek  opportunities  for  dual  sourcing.  We  particularly  try  to  pursue  competition  at  the  subcontractor 
and  vendor  levels.  Because  our  procurement  programs  are  funded  on  an  annual  basis,  however,  we 
do  not  get  credit  (in  a  competitive  sense)  for  follow-on  buys  for  programs  which  reaped  the  benefits 
of  competition  earlier.  It  makes  no  sense,  for  example,  to  develop  a  second  source  for  an  F- 15  or  F- 16 
aircraft  at  this  point.  These  programs  experienced  vigorous  competition  early  in  their  development. 
The  same  is  true  for  most  of  our  major  programs.  This  is  just  another  area  where  we  suffer  bad  press 
for  something  which  is  really  not  a  problem. 

6.3.3  Organization  of  DoD  Acquisition  Management 

A  number  of  organizations  and  offices  play  a  variety  of  roles  in  the  defense  acquisition  process 
within  the  context  of  the  management  philosophy  I  have  described.  Let  me  briefly  summarize  some 
of  the  more  important  and  discuss  their  respective  roles:  I  have  already  mentioned  the  DRB  and  the 
vital  role  which  it  plays.  Of  course,  there  is  also  the  Under  Secretary  of  Defense  (Research  and 
Engineering/Defense  Acquisition  Executive).  As  the  principal  advisor  to  the  Secretary  on  scientific 
and  acquisition  issues,  I  exercise  oversight  on  scientific  and  technical  matters  of  basic  applied  research, 
and  the  development  and  acquisition  of  our  weapons  systems.  It  is  my  duty  to  ensure  that  activities 
in  these  areas  adhere  to  departmental  policies  and  national  security  objectives.  I  participate  in  the  review 
and  evaluation  of  requirements  and  priorities  and  make  certain  that  our  programs  are  designed  to 
accommodate  operational  requirements.  It  is  also  my  responsibility  to  follow  up  and  evaluate  programs 
for  carrying  out  approved  acquisition  policies  and  standards.  Through  my  participation  in  the  planning, 
programming,  and  budgeting  system,  1  review  proposed  programs  and  resources  and  recommend  resource 
allocations  in  accordance  with  national  security  policy  and  priorities.  Finally,  as  Defense  Acquisition 
Executive  (DAE),  I  serve  as  the  chairman  of  the  Defense  Systems  Acquisition  Review  Council  (DSARC) 
which  exercises  oversight  and  advises  the  Secretary  on  the  management  process,  policies,  and  procedures 
for  acquiring  our  major  programs. 

Though  the  list  of  my  duties  and  other  organizational  commitments  could  go  on,  let  me  just 
emphasize  an  important  aspect  of  my  job  about  which  some  of  the  members  of  the  [Senate  Armed 
Services]  Committee  have  indicated  concern.  The  concern  involves  an  apparent  conflict  of  interest  between 
my  role  as  manager  of  research  and  engineering  and  as  the  director  of  acquisition. 

Quite  frankly,  for  a  variety  of  reasons,  I  see  no  conflict  at  all.  First,  there  is  considerable  overlap 
between  the  functions  of  development  and  production  which  requires  constant  oversight  in  order  to 
manage  the  transition  effectively.  Development  and  production  cannot  be  neatly  separated.  My  office 
possesses  the  technical  and  management  skills  to  exercise  effective  oversight  in  this  area. 

Second,  by  virtue  of  my  role  in  the  planning,  programming,  and  budgeting  process,  as  well  as 
my  position  as  DAE,  1  can  help  to  ensure  that  consistency  exists  between  our  policies  and  requirements 
and  the  systems  which  we  acquire.  Although  the  ultimate  responsibility  regarding  this  fundamental 
objective  is  shared  by  the  Secretary,  the  President,  and  the  Congress,  the  important  pieces  of  the  puzzle 
must  begin  to  fit  together  at  some  point  in  the  management  process.  My  duties  assure  that  this  process 
can  appropriately  be  undertaken  in  the  office  of  the  Under  Secretary  for  Research  and  Engineering. 

Another  important  element  within  the  Deparment’s  oversight  function  was  instituted  by  the  Secretary 
shortly  after  he  took  office.  Each  week  on  a  rotating  basis,  the  service  secretaries  report  to  the  Secretary 
on  one  or  two  major  programs  to  discuss  problems  and  possible  solutions.  For  some  of  our  more  critical 


systems,  program  personnel  provide  regular  reports  directly  to  the  Secretary  on  a  biweekly  or  monthly 
basis.  These  Secretarial  Performance  Reviews  are  an  essential  part  of  the  management  philosophy  1 
described  at  the  outset  of  my  statement:  high  level  oversight  of  high  priority  major  issues. 

No  discussion  of  acquisition  management  is  complete  without  recognizing  the  hard  work 
accomplished  by  the  various  program  offices,  the  buying  commands,  the  Joint  Logistics  Commanders, 
and  the  Defense  Logistics  Agency.  The  personnel  employed  in  these  organizations  perform  an  outstanding 
job  of  executing  the  programs,  policies,  and  procedures  which  confront  them  daily.  We  are  doing  our 
best  to  make  their  jobs  easier  through  various  acquisition  refoims  such  as  reducing  the  number  of 
directives  and  carefully  screening  contractual  data  requirements.  We  maintain  close  contact  with  the 
Joint  Logistics  Commanders  to  ensure  that  these  and  other  important  acquisition  reforms  which  affect 
the  buying  community  are  fully  implemented. 


6.3.4  Oversight 

The  Inspector  General  (IG)  is  another  important  participant  in  the  acquisition  management  oversight 
function.  The  IG  performs  essential  audits  and  reviews  to  ensure  that  waste,  fraud,  and  abuse  are  purged 
from  the  system.  In  addition,  we  receive  valuable  insights  on  how  to  improve  the  acquisition  management 
process  from  the  Council  on  Integrity  and  Management  Inprovement  (CIMI)  which  is  chaired  by  the 
Deputy  Secretary.  The  Council  is  a  high  level  group  which  meets  to  explore  new  ideas  and  opportunites 
for  progress  in  management  on  a  DoD-wide  basis.  Specific  management  issues  are  regularly  considered 
and  the  Council  makes  recommendations  to  the  Secretary  for  his  resolution.  The  Defense  Science  Board 
is  another  important  organization  which  is  external  to  the  Department  and  which  draws  together 
management  ideas  from  key  elements  within  DoD,  industry,  academia,  and  the  scientific  community. 

Finally,  I  must  recognize  my  “right-hand  woman”  who  serves  as  the  Deputy  for  Acquisition 
Management.  Mary  Ann  Gilleece  is  my  principal  advisor  on  acquisition  matters  and  is  the  primary 
policy  maker  for  all  DoD  procurement  and  production  policy.  She  is  responsible  for  implementing 
federal  policies  on  acquisition,  the  formulation  and  revision  of  defense  acquisition  regulations, 
specifications  and  standards,  and  other  policies.  Ms.  Gilleece  is  also  my  principal  advisor  in  deliberations 
of  the  DSARC  on  acquisition  matters,  including  the  implementation  of  acquisition  improvement  program 
initiatives. 

The  members  of  this  committee  are  doubtless  aware  of  many  of  the  important  strides  we  have 
made  in  implementing  various  initiatives  of  the  (Acquisition  Improvement  Programs  (AIP)].  I  won’t 
review  in  detail  the  progress  we  have  made  through  the  good  efforts  of  Ms.  Gilleece  and  many  others, 
but  let  me  highlight  some  changes  we  have  initiated  within  the  DSARC  process  which  make  our 
management  more  efficient  and  effective. 


6.3.5  DSARC  [Defense  Systems  Acquisition  Review  Council] 

[DSARC  is  an  OSD-level  recommending  body  that  is  in  the  decisionmaking  process,  but  does  not 
provide  funds.]  First,  as  I  stated  at  the  outset,  we  have  instituted  controlled  decentralization  throughout 
the  process.  The  Service  secretaries,  for  example,  now  serve  as  full  members  of  the  DSARC  and  contribute 
to  policy  formulation  and  program  execution.  [Other  members  of  the  council  include  the  USDRE 
chairman,  USD  (Policy),  ASD  (MI&L),  ASD  (C),  DIR  (PA&E),  chairman  of  the  JCS,  and  DIR  (OT&E).] 
At  the  same  time,  we  have  streamlined  the  acquisition  process  in  order  to  accelerate  the  results  and 
avoid  micromanagement.  The  front-end  review  of  new  programs  is  now  done  during  the  POM  review 
process  to  ensure  that  the  new  starts  are  both  required  and  affordable. 


In  addition,  by  revising  the  threshold  which  defines  a  major  system  to  $200  million  in  R&D  and 
$1  billion  in  procurement,  we  have  ensured  that  high  level  management  attention  is  placed  on  programs 
of  major  significance.  Major  milestone  decisions  on  10  programs  were  delegated  back  to  the  services 
when  we  instituted  this  change  in  1981,  and  milestone  decisions  for  an  additional  10  or  so  programs 
have  been  precluded  from  the  DSARC  process  since  that  time.  Partly  as  a  consequence,  DSARC  activity 
during  the  last  3  years  has  decreased  significantly  from  12  meetings  in  1981  to  5  meetings  thus  far  in 
1983.  I  should  add  that  much  of  what  might  have  required  a  DSARC  in  the  past  has  been  replaced 
by  much  less  formal  program  reviews  which  focus  on  specific  major  problem  areas.  Fewer  prereviews 
and  reduced  documentation  have  been  a  major  benefit. 

All  major  programs  proceed  through  the  DSARC  process  to  milestone  II  when  a  program  is  baselined 
at  full-scale  development.  If  a  program  stays  within  baseline  objectives,  the  final  production  decision 
is  made  at  the  appropriate  management  level,  i.e.,  the  Service.  If  a  program  exceeds  its  baseline  objectives, 
however,  it  remains  subject  to  further  DSARC  review  before  a  production  go-ahead  can  be  given. 

At  each  DSARC  milestone  we  review  acquisition  strategy  and  examine  the  potential  for  competition, 
including  the  possibility  for  dual  sourcing.  We  ensure  that  support  and  readiness  are  given  proper 
consideration,  and  determine  whether  a  program  meets  the  criteria  to  become  a  multiyear  candidate. 
In  addition,  greater  emphasis  is  now  being  placed  in  the  DSARC  on  improved  production  engineering 
preparation  to  ease  the  difficult  transition  from  development  to  manufacturing.  We  also  examine  other 
AIP  initiative  areas  such  as  the  potential  to  apply  a  preplanned  product  (P3)  improvement  approach. 
In  addition,  the  Cost  Analysis  Improvement  Group  (CAIG)  examines  cost  estimates  at  each  milestone 
in  order  to  ensure  realistic  budget  estimates.  In  short,  each  DSARC  meeting  is  an  opportunity  to  confirm 
that  the  acquisition  policies  we  have  adopted  are  being  considered  and  executed  properly  at  lower  levels 
of  management.  The  DSARC  process  is  alive  and  well  and  more  effective  than  ever  as  a  means  to 
improve  our  management  of  the  acquisition  process. 


6.3.6  Other  Management  Issues 

The  Committee  has  also  indicated  its  interest  in  the  area  of  joint  service  program  management 
as  a  means  to  increase  efficiency  and  otherwise  reduce  the  aggregate  costs  of  weapons  systems 
development  and  procurement.  Although  the  benefits  of  joint  service  programs  can  be  attractive, 
expensive  failures  have  occurred  too  often  in  the  past  and  counsel  caution  as  we  proceed  forward. 
A  balanced  approach  is  needed  whereby  specific  service  requirements  are  carefully  examined  to  ensure 
compatibility  before  proceeding  on  a  joint  basis.  Our  basic  goal  is  to  increase  cross-service  coordination 
in  the  development  and  use  of  the  systems  and  technology  of  similar  purposes  to  obtain  maximum 
performance  at  minimum  cost. 

Some  recent  examples  where  we  are  making  important  progress  involve  joint  activities  in  specific 
mission  areas.  The  Navy  and  the  Air  Force,  for  example,  have  achieved  important  progress  in 
coordinating  their  efforts  regarding  Fleet  air  defense  and  sea  control.  The  decision  to  designate  a  number 
of  B-52s  to  support  the  Navy’s  sea  contro1  mission  is  a  good  example  of  the  benefits  of  improved  cross¬ 
service  coordination  and  management.  Similar  efforts  are  being  conducted  in  the  deep  interdiction  mission 
area  where  hardware  development  as  well  as  employment  doctrine  and  concepts  are  being  examined 
on  a  joint  basis.  We  are  confident  that  the  results  of  this  joint  effort  will  produce  an  effective  means 
to  solve  the  second  echelon  problem  in  the  most  economical  way  possible. 


6.3.7  Joint  Requirements  and  Management  Board 

We  are  considering  some  important  steps  to  institutionalize  our  approach  and  practices  concerning 
joint  service  programs.  As  a  result  of  a  study  conducted  this  past  summer  by  the  Defense  Science  Board, 
a  Joint  Requirements  and  Management  Board  comprising  the  service  Vice-Chiefs,  the  Director  of  the 
Joint  Staff,  and  OSD  components  is  being  contemplated.  The  Board’s  primary  purpose  would  be  to 
provide  a  rigorous  review  of  the  requirements  process  and  identify  those  with  potential  for  joint  service 
applicability.  The  Board  would  provide  a  more  systematic  way  of  examining  the  possibilities  for  joint 
programs  than  we  have  had  in  the  past. 

Another  area  of  particular  interest  these  days  concerns  the  acquisition  of  spare  parts;  the  horror 
stories  have  created  understandable  concern  among  all  of  us.  First,  may  I  point  out  that  our  system 
of  management  works.  Employees  of  the  Department  discovered  and  reported  the  problem,  and  the 
management  of  the  Department  has  taken  corrective  measures.  Secretary  Weinberger’s  10  points  program 
on  spare  parts  procurement  reform  has  already  revised  much  of  the  way  in  which  we  do  business. 

Contracts  to  purchase  spares  are  being  written  to  ensure  that  spares  are  purchased  competitively 
to  the  maximum  extent  possible.  Steps  are  being  taken  to  ensure  that  manufacturers  of  parts  are  identified 
and  that  complete  technical  data  packages  become  available  so  that  we  appoint  at  the  mercy  of  the 
prime  contractor  in  the  future.  The  bidders  for  the  new  fighter  engine  (Pratt  and  Whitney  and  General 
Electric)  are  being  required  to  submit  plans  to  show  how  they  will  develop  two  or  more  qualified 
subcontractors  who  would  remain  available  for  production  of  the  30  replenishment  spares  with  the 
highest  procurement  value.  Since  those  high  value  parts  comprise  about  80  percent  of  the  value  of 
the  engine,  we  can  focus  our  efforts  on  gaining  competition  for  the  remaining  20  percent. 

In  addition,  we  are  building  incentives  and  disincentives  into  the  spares  management  process.  The 
Air  Force  sergeant  who  reported  a  case  of  pricing  abuse  was  recently  awarded  $1,100  (the  amount 
the  Air  Force  was  being  charged  for  the  spare  part).  Where  an  employee’s  negligence  has  contributed 
to  excessive  prices,  we  are  taking  disciplinary  action.  Where  industry  is  at  fault,  we  will  use  every  legal 
means  to  obtain  refunds  in  case  of  overcharge. 

The  Department  and  the  Congress  are  partners  in  the  process  of  acquisition  management.  I  have 
attempted  to  describe  just  a  few  of  the  major  characteristics  and  objectives  of  the  departmental  acquisition 
organization  and  management  for  you  today.  However,  our  organization  and  its  efforts  cannot  be 
successful  unless  every  member  of  this  Committee  and  the  Congress  as  a  whole  understands  their  purpose 
and  potential  benefit.  Moreover,  each  member  of  Congress  should  simultaneously  consider  the 
appropriate  management  role  of  the  legislative  branch  in  the  acquisition  process.  Are  national  or  parochial 
interests  being  served  when  Congress  votes  in  a  particular  way?  Is  national  security  truly  enhanced? 
When  the  Congress  votes  to  reduce  funds  for  a  particular  program,  do  the  members  understand  the 
cost  impact  for  the  future?  Certainly,  the  answers  to  these  questions  vary  from  member  to  member. 
The  concepts,  however,  are  important  to  bear  in  mind  lest  we  seek  inappropriate  microsolutions  to 
problems  which  are  truly  macro  in  nature. 

[Figures  6.1  and  6.2  present  the  life  cycle  of  typical  major  system  acquisitions  and  life-cycle  costing 
for  those  acquisitions.] 


6.4  THE  DEPARTMENT  OF  DEFENSE  ORGANIZATIONAL  STRUCTURE 


6.4.1 
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Figure  6.1.  The  life  cycle  of  major  system  acquisitions. 
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Figure  6.2.  Life  cycle  costing  in  system  acquisition. 


6.4.1.1  The  Department  of  Defense  (DoD)  (DoD  Directive  5100.1).  DoD  is  responsible  for  providing 
the  military  forces  needed  to  deter  war  and  protect  the  security  of  the  United  States.  The  major  elements 
of  these  forces  are  the  Army,  Navy,  Air  Force,  and  Marine  Corps.  Under  the  President,  who  is  also 
Commander-in-Chief,  the  Secretary  of  Defense  exercises  direction,  authority,  and  control  over  the 
Department  which  includes  the  Office  of  the  Secretary  of  Defense,  organization  of  the  Joint  Chiefs 
of  Staff  ,hree  military  departments,  nine  unified  and  specified  commands,  the  DoD  Inspector  General, 
twelve  detense  agencies,  and  six  OSD  field  activities  (Figure  6.3). 

In  order  to  support  the  forces  that  DoD  provides,  the  acquisition  of  major  systems  is  an  inevitable 
necessity.  Some  brief  definitions  should  be  helpful  for  considering  the  items  in  this  section.  A  major 
system  exhibits  the  following  characteristics: 

a.  It  has  been  determined,  at  the  discretion  of  the  agency’s  head  (e.g.,  the  Secretary  of  Defense), 
to  be  critical  to  fulfilling  the  agency’s  mission. 

b.  It  entails  the  allocation  of  relatively  large  resources. 

c.  It  warrants  special  management  attention. 

Besides  having  the  characteristics  noted  above,  a  DoD  major  system  has  been  designated  as  such  based 
on  the  following  considerations: 

a.  Risk,  need,  or  other  item  of  SECDEF  interest 

b.  Joint  service  or  multinational  acquisition 

c.  Estimated  RDT&E  and  procurement  funds 

d.  Estimated  operations,  maintenance,  and  support  manpower  requirements 

e.  Congressional  interest. 

DoD  Directive  5000.1  describes  major  systems  and  DoD  major  systems  in  greater  detail.  The  directive 
emphasizes  the  following  themes: 

a.  Flexibility  (tailored  acquisition  strategy) 

b.  Minimize  time  to  field  new  capability 

c.  Balance  between  cost  and  effectiveness 

d.  Linkage  with  PPBS 

e.  Maximize  collaboration  with  allies 

f.  Integration  of  support  considerations  into  process 

g.  Integration  of  threat  considerations  into  process 

h.  Decentralization: 

SECDEF— two  milestone  decisions  on  major  systems  services— all  other  management  on 
major  systems. 

The  directive  addresses  the  management  of  nonmajor  programs  as  well.  “The  management  principles 
and  objectives  in  this  Directive  (DoDD  5000.1)  shall  also  be  applied  to  the  acquisition  of  defense  systems 
not  designated  as  major.”  This  particularly  includes  tailored  application  and  decentralized  management 
responsibility. 

Examples  of  current  major  systems  are  listed  in  Table  6.1. 

6.4.1.2  The  Office  of  the  Secretary  of  Defense  (OSD).  OSD  is  the  principal  staff  element  of  the 
Secretary  in  the  exercise  of  policy  development,  planning,  resource  management,  fiscal,  and  program 
evaluation  responsibilities  (Figure  6.4).  OSD  includes  the  immediate  offices  of  the  Secretary  and  Deputy 
Secretary  of  Defense,  Under  Secretary  of  Defense  for  Policy,  Under  Secretary  of  Defense  for  Research 
and  Engineering  (USDRE),  Assistant  Secretaries  of  Defense,  General  Counsel,  Assistants  to  the  Secretary 
of  Defense,  and  such  other  staff  offices  as  the  Secretary  establishes  to  assist  in  carrying  out  assigned 
responsibilities. 


Figure  6.3.  The  Department  of  Defense. 


Table  6.1.  Current  major  systems. 
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The  organizational  struture  of  USDRE  is  presented  in  Figures  6.5  and  6.6.  The  USDRE  has  three 
major  roles: 

a.  Principal  advisor  to  the  SECDEF  for  scientific  and  technical  matters 

b.  Defense  acquisition  executive  (DSARC  chairman) 

c.  U.S.  representative  to  the  NATO  Conference  of  National  Armament  Directors  (CNAD). 

6.4.1.3  The  Military  Departments  (DoD  Directive  5100.1).  These  include  the  Departments  of  the 
Army,  Navy,  and  Air  Force  (the  Marine  Corps  is  a  part  of  the  Department  of  theNa/y).  Each  military 
department  is  separately  organized  under  its  own  Secretary  and  functions  under  the  direction,  authority, 
and  control  of  the  Secretary  of  Defense.  The  military  departments  are  responsible  for  organizing,  training, 
supplying,  and  equipping  forces  for  assignment  to  the  unified  and  specified  commands  (U/S  Commands). 

6.4.1.4  The  Joint  Chiefs  of  Staff  (JCS)  (DoD  Directive  5100.1).  The  JCS  are  the  principal  military 
advisors  to  the  Secretary  of  Defense  as  well  as  to  the  President  and  the  National  Security  Council. 
Members  of  the  Joint  Chiefs  of  Staff,  other  than  the  Chairman,  are  the  senior  military  officers  of 
their  respective  Services  and  are  responsible  for  keeping  the  Secretaries  of  the  military  departments 
fully  informed  on  matters  considered  or  acted  upon  by  the  Joint  Chiefs  of  Staff. 

6.4. 1.5  The  Armed  Forces  Policy  Council  (AFPC)  (DoD  Directive  5105.3).  The  AFPC  advises  the 
Secretary  of  Defense  on  matters  of  broad  policy  relating  to  the  Armed  Forces  and  such  other  matters 
as  the  Secretary  may  direct.  Its  members  report  regularly  on  important  matters  under  their  cognizance 
which  are  of  interest  to  the  Department  of  Defense.  In  addition  to  members  identified  below,  such 
other  officials  of  the  Department  of  Defense,  and  other  departments  and  agencies  in  the  Executive 
Branch  as  may  be  designated  by  the  Secretary  of  Defense,  are  invited  to  attend  appropriate  meetings 
of  the  AFPC.  Council  membership  is  as  indicated: 

Secretary  of  Defense,  Chairman 
Deputy  Secretary  of  Defense 
Secretaries  of  the  Military  Departments 
Chairman,  Joint  Chiefs  of  Staff 
Under  Secretaries  of  Defense 
Chief  of  Staff,  Army 
Chief  of  Naval  Operations 
Chief  of  Staff,  Air  Force 
Commandant,  Marine  Corps 

6.4. 1.6  The  Unified  and  Specified  Commands  (U/S  Commands)  (DoD  Directive  5100.1).  The  U/S 
Commands  are  responsible  to  the  President  and  the  Secretary  of  Defense  for  the  accomplishment  of 
the  military  missions  assigned  to  them.  Combatant  units  of  the  military  departments  are  assigned  to, 
and  under  the  operational  command  of,  Commanders  of  unified  and  specified  commands.  Unified 
commands  are  composed  of  assigned  components  of  two  or  more  Services.  They  include  the  European 
Command,  Pacific  Command,  Atlantic  Command,  Southern  Command,  Readiness  Command,  and 
Central  Command.  Specified  commands  are  usually  composed  of  forces  from  one  Service,  but  may 
include  units  and  have  representation  from  other  Services.  They  include  the  Aerospace  Defense 
Command,  Strategic  Air  Command,  and  Military  Airlift  Command.  The  military  chain  of  command 
runs  from  the  President  to  the  Secretary  of  Defense  and,  through  the  Joint  Chiefs  of  Staff,  to  the 
Commanders  of  unified  and  specified  commands.  Orders  to  these  Commanders  are  issued  by  the 
President  or  the  Secretary  of  Defense,  or  by  the  Joint  Chiefs  of  Staff  by  authority  and  direction  of 
the  Secretary  of  Defense. 
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FlKure  6.5.  Office  of  the  Under  Secretary  of  Defense  for  Research  and  Engineering. 
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Figure  6.6.  Under  Secretary  of  Defense— Research  &  Engineering. 
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6.4.1.7  The  Inspector  General  (IG)  of  the  Department  of  Defense  (DoD  Directive  5106.1).  The  IG, 
under  the  provisions  set  forth  by  Public  Law  95-452,  serves  as  an  independent  and  objective  official 
in  the  Department  of  Defense  who  is  responsible  for  conducting,  supervising,  monitoring,  and  initiating 
audits  and  investigations  relating  to  programs  and  operations  of  the  Department  of  Defense.  The 
Inspector  General  provides  leadership  and  coordination  and  recommends  policies  for  activities  designed 
to  promote  economy,  efficiency,  and  effectiveness  in  the  administration  of,  and  to  prevent  and  detect 
fraud  and  abuse  in,  such  programs  and  operations.  The  Inspector  General  is  also  responsible  for  keeping 
the  Secretary  of  Defense  and  the  Congress  fully  and  currently  informed  about  problems  and  deficiencies 
relating  to  the  administration  of  such  programs  and  operations  and  the  necessity  for,  and  progress 
of,  corrective  action. 


6.4.1.8  The  Defease  Agencies.  These  agencies,  authorized  by  the  Secretary  of  Defense  pursuant  to 
the  provisions  of  Title  10,  United  States  Code,  perform  selected  support  and  service  functions  on  a 
Departmentwide  basis. 

6.4.1.9  The  OSD  Field  Activities.  These  field  activities  are  established  by  the  Secretary  of  Defense,  * 
under  the  provisions  of  Title  10,  United  States  Code,  to  perform  selected  support  and  service  functions 
of  a  more  limited  scope  than  the  defense  agencies. 

6.4.1.10  The  Uniformed  Services  University  of  the  Health  Sciences  (USUHS)  (DoD  Directive 
5105.45).  The  USUHS,  under  the  policy  guidance  of  the  Secretary  of  Defense  and  operational  direction 
of  a  Board  of  Regents,  is  a  fully  accredited  4-year  School  of  Medicine  whose  primary  mission  is  to 
select,  educate,  and  train  qualified  applicants  to  become  military  physicians.  The  curriculum  is  expanded 
from  that  of  the  civilian  schools  to  include  subjects  of  specific  military  importance,  such  as  command 
and  control,  tropical  medicine,  environmental  extremes,  occupational  hazards,  nonconventional  weapons, 
wartime  surgery,  and  public  health.  USUHS  also  has  educational  programs  leading  to  the  Ph.D.  degree 
in  the  basic  medical  sciences,  a  Masters  of  Public  Health  program,  and  a  continuing  medical  education 
program. 


6.4.2  Organizations  and  Functions— Office  of  the  Secretary  of  Defense 

The  Office  of  the  Secretary  of  Defense  (OSD)  is  the  principal  staff  element  used  by  the  Secretary 
of  Defense  to  exercise  direction,  authority,  and  control  over  the  Department  of  Defense.  The  mission 
of  OSD  as  an  organizational  entity,  in  coordination  with  other  elements  of  DoD,  is  as  follows: 

Develop  and  promulgate  policies  in  support  of  United  States  national  security  objectives. 

Provide  oversight  to  assure  the  effective  allocation  and  efficient  management  of  resources  consistent 
with  Secretary  of  Defense  approved  plans  and  programs. 

Develop  appropriate  evaluation  mechanisms  to  provide  effective  supervision  of  policy 
implementation  and  program  execution  at  all  DoD  levels. 

Provide  the  focal  point  for  departmental  participation  in  the  United  States  security  community 
and  other  Government  activities. 

In  addition,  each  OSD  principal  staff  official,  in  his  or  her  respective  areas  of  functional  assignment, 
is  responsible  for  performing  the  following: 

Conduct  analyses,  develop  policies,  provide  advice,  make  recommendations,  and  issue  guidance 
on  DoD  plans  and  programs. 
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Develop  systems  and  standards  for  the  administration  and  management  of  approved  plans  and 
programs. 

Initiate  programs,  actions,  and  taskings  to  ensure  adherence  to  DoD  policies  and  national  security 
objectives  and  to  ensure  that  programs  are  designed  to  accommodate  operational  requirements. 

Review  and  evaluate  programs  for  carrying  out  approved  policies  and  standards. 

inform  appropriate  organizations  and  personnel  of  new  and  significant  trends  or  initiatives  in 
assigned  areas  of  functional  responsibilities. 

Review  proposed  resource  programs,  formulate  budget  estimates,  recommend  resource  allocations, 
and  monitor  the  implementation  of  approved  programs. 

Participate  in  those  planning,  programming,  and  budgeting  activities  that  relate  to  assigned  areas 
of  functicnal  responsibilities. 

Review  and  evaluate  recommendations  on  requirements  and  priorities. 

Promote  coordination,  cooperation,  and  mutual  understanding  within  the  Department  of  Defense 
and  between  DoD  and  other  Federal  agencies  and  the  civilian  community. 

Serve  on  boards,  committees,  and  other  groups  pertaining  to  assigned  functional  areas,  and  represent 
the  Secretary  of  Defense  on  matters  outside  the  Department  of  Defense. 

Develop  information  and  data,  prepare  reports,  and/or  testimony  for  presentations  to  congressional 
committees  or  in  response  to  congressional  inquiries. 

Represent  the  DoD  with  congressional  committees  or  individual  Members  of  the  Congress. 
Perform  such  other  duties  as  the  Secretary  of  Defense  may  from  time  to  time  prescribe. 

6.4.2.1  Immediate  Offices  of  the  Secretary  and  Deputy  Secretary  of  Defense.  The  Secretary  of 
Defense  is  the  principal  defense  policy  advisor  to  the  President  and  is  responsible  for  the  formulation 
of  general  defense  policy,  for  policy  related  to  all  matters  of  direct  and  primary  concern  to  the  DoD, 
and  for  the  execution  of  approved  policy.  Under  the  direction  of  the  President  and  subject  to  the 
provisions  of  the  National  Security  Act  of  1947,  as  amended,  the  Secretary  exercises  direction,  author¬ 
ity,  and  control  over  the  Department  of  Defense. 

The  Deputy  Secretary  of  Defense  assists  in  the  administration  of  the  Department.  The  Deputy 
Secretary  is  delegated  full  power  and  authority  to  act  for  the  Secretary  of  Defense  and  to  exercise  the 
powers  of  the  Secretary  upon  any  and  all  matters  concerning  which  the  Secretary  is  authorized  to  act 
pursuant  to  law. 

The  Executive  Secretary  of  the  Department  of  Defense  supports  the  Secretary  and  Deputy  Secretary 
by  executing  the  following  responsibilities:  coordinates  DoD  participation  in  the  interagency  process 
involving  national  security  management,  defense  policy,  programs  and  resources  for  the  DoD,  with 
the  White  House,  the  NSC,  State  Department,  CIA,  and  other  agencies  as  appropriate;  is  the  Secretariat 
for  both  the  Armed  Forces  Policy  Council  (AFPC)  and  the  Secretary’s  Performance  Review  (bPR) 
Board;  performs  liaison  with  the  White  House  Military  Office,  including  Presidential  support  activities; 
serves  as  the  DoD  point  of  contact  for  intergovernmental  affairs;  processes  requests  for  DoD  support 
from  the  White  House  and  other  departments/agencies;  processes  Special  Air  Mission  (SAM) 
transportation  requests  for  OSD  and  non-DoD  agencies;  manages  and  controls  all  correspondence, 
information,  and  action  documents  for  the  Secretary  and  Deputy  Secretary;  and  performs  any  special 
project  directed  by  either  the  Secretary  or  Deputy  Secretary. 

The  Assistant  to  the  Secretary  and  Deputy  Secretary  for  Executive  Personnel  is  responsible  for 
staffing  noncareer  positions  throughout  the  DoD,  approval  of  staffing  for  DoD  boards  and  committees, 
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recommending  candidates  for  Presidential  boards  and  committees,  approving  appointment  of  DoD 
headquarters  level  experts  and  consultants;  acts  as  noncareer  DoD  contact  with  Office  of  Assistant 
to  the  President  for  Intergovernmental  Affairs,  and  serves  as  primary  DoD  liaison  with  the  White  House 
Personnel  Office  in  dealing  with  such  matters. 

6.4.2.2  Under  Secretary  of  Defense  (Policy)  (USD  (P)>  (DoD  Directive  5111.1).  Under  the  direction 
of  the  Secretary  of  Defense,  the  USD(P)  is  responsible  for  the  following  functions: 

Integration  of  DoD  plans  and  policies  with  overall  national  security  objectives 

Representation  of  DoD  as  directed  in  matters  involving  the  National  Security  Council,  Department 
of  State  and  the  intelligence  community,  and  other  departments,  agencies,  and  interagency  groups 
with  responsibilities  in  the  national  security  area 

Oversight  and  coordination  of  the  formulation  and  implementation  of  DoD  planning  and  policy 
concerning  political-military  affairs,  such  as  arms  limitation  negotiations;  contingency  planning; 
intelligence  analyses  and  collection  requirements;  nuclear  weapons  and  targeting;  communications, 
command,  and  control  (C3);  and,  the  use  of  outer  space 

Oversight  and  coordination  of  policy  review  concerning  intelligence  planning  and  requirements, 
counterintelligence  and  investigative  programs,  security  plans  and  programs,  and  sensitive  intelligence 
matters  including  arrangements  with  foreign  governments 

Review  of  evaluations  and  the  development  of  recommendations  to  the  Secretary  of  Defense 
concerning  plans  and  requirements  for,  and  capabilities  of,  existing  or  proposed  United  States 
or  foreign  forces  and  their  deployment  with  particular  attention  to  performance  of  missions  which 
are  or  may  be  critical  in  consideration  of  United  States  national  security  policy 

Coordination  of  DoD  participation  in  the  preparation  of,  and  followthrough  on,  NATO  Short- 
Term  Initiatives  and  Long-Term  Programs,  and  the  integration  of  NATO  considerations  in  the 
development  and  formulation  of  DoD  decisions 

L  aw  of  the  Sea 

Military  Assistance  Advisory  Groups  (MAAG)  and  missions  pertaining  to  security  assistance. 
Negotiation  and  monitoring  of  agreements  with  foreign  governments 

Development  of  DoD  policy  positions,  recommendations,  and  coordination  of  all  matters  concerning 
disarmament  and  arms  control  to  include  START  and  MBFR  and  other  Defense-related  international 
negotiations 

DoD  focal  point  for  long  and  midrange  policy  planning  on  strategic  international  security  matters 

Formulation  of  policy  related  to  strategic  offensive  and  defensive  forces,  theater  nuclear  matters 
and  capabilities,  arms  control  negotiations,  and  the  relationship  between  strategic  and  theater  force 
planning  and  budgets 

Oversight  of  DoD  activities  related  to  the  North  Atlantic  Treaty  Organization  and  East-West 
economic  policy,  including  East-West  trade,  technology  transfer  issues,  and  issues  affecting  the 
defense  industrial  mobilization  base 

Formulating,  planning,  conducting,  and  preparing  net  assessments  for  the  Secretary  of  Defense 

Formulating  plans  and  policy  related  to  general  purpose  forces,  non-European  regional  security 
requirements,  and  related  budget  considerations 

Developing  policies,  plans,  and  procedures  for  the  discharge  of  Department  of  Defense  functions 
in  national  emergencies;  providing  support  to  DoD  and  other  U.S.  Government  or  State  agencies 
on  civil  defense  and  related  matters. 
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These  functions  are  carried  out  through  the  following  key  personnel: 

Deputy  Under  Secretary  of  Defense  for  Policy 

Assistant  Secretary  of  Defense  (International  Security  Affairs) 

Assistant  Secretary  of  Defense  (International  Security  Policy) 

Director  of  Net  Assessment. 

In  addition,  the  Under  Secretary  of  Defense  for  Policy  exercises  direction,  authority,  and  control 
over  the 

Defense  Investigative  Service 
Defense  Security  Assistance  Agency 


6.4.2.3  Under  Secretary  of  Defense  (Research  and  Engineering)  (USDRE)  (DoD  Directive 
5126.1).  Under  the  direction  of  the  Secretary  of  Defense,  the  USDRE  is  responsible  for  the  following 
functions: 


l 

i 
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Scientific  and  technical  information 
Basic  and  applied  research 

Design  and  engineering,  including  life-cycle  considerations 

Development  and  acquisition  of  weapon  systems,  including  procurement  policy  and  production 
planning.  This  function  includes  national,  strategic,  and  tactical  communications;  command  and 
control;  and  intelligence  activities. 

Development  test  and  evaluation  in  accordance  with  DoD  Directive  5000.3,  to  include  review  and 
appiovai  of  tht  'ME  Master  Plan  (TEMP) 

Environmental  services 

Assignment  and  reassignment  of  research,  engineering,  and  acquisition  responsibility  for  systems, 
activities,  and  programs 

Coproduction  and  research  interchange  with  friendly  and  allied  nations,  in  conjunction  with  the 
Under  Secretary  of  Defense  for  Policy 

Contract  placement  and  administration  for  research,  development,  and  weapon  systems  acquisition 
programs 

Military  applications  of  atomic  energy,  nuclear  weapons  development  and  acquisition,  security, 
safety,  R&D,  deployment,  employment  and  targeting,  and  theater  nuclear  force  modernization. 

The  above  functions  are  carried  out  with  the  support  of  the  following  key  personnel: 
Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and  Intelligence) 
Assistant  Secretary  of  Defense  (Development  and  Support) 

Assistant  Secretary  of  Defense  (Research  and  Technology) 

Assistant  to  the  Secretary  of  Defense  (Atomic  Energy) 

Deputy  Under  Secretary  (Acquisition  Management) 

Deputy  Under  Secretary  (International  Programs  and  Technology) 

Deputy  Under  Secretary  (Research  and  Advanced  Technology) 

Deputy  Under  Secretary  (Strategic  and  Theater  Nuclear  Forces) 


c. 
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Deputy  Under  Secretary  (Tactical  Warfare  Programs) 
Director,  Test  and  Evaluation. 


In  addition,  the  USDRE  exercises  direction,  authority,  and  control  over 

Defense  Advanced  Research  Projects  Agency 

Defense  Communications  Agency 

Defense  Mapping  Agency 

Defense  Nuclear  Agency 


6.4.2.4  Assistant  Secretary  of  Defense  (Comptroller)  (ASD(C))  (DoD  Directive  5118.3).  Under  the 
direction  of  the  Secretary  of  Defense,  the  ASD(C)  is  responsible  for  the  following  functions: 

Planning,  programming,  and  budgeting  system  (PPBS),  including  programming  coordination  and 
control 

DoD  budget  formulation  and  execution,  resources  allocation,  and  surveillance  over  utilization 
Focal  point  for  budgeted  savings  under  economy  and  efficiency  initiatives 
Information  to  support  justification  of  the  budget  to  Congress 

Focal  point  for  joint  OSD  and  Office  of  Management  and  Budget  (OMB)  review  of  the  budget 

Coordination  with  OMB  on  management  reviews  and  analyses  performed  in  connection  with  the 
budget  process 

Initiatives  to  strengthen  Departmentwide  resource  management  and  to  improve  management 
information  provided  to  senior  officials 

Financial  management  including  financial  accounting  and  reporting  systems;  internal  control 
systems;  pricing  policy  including  Foreign  Military  Sales  pricing;  banking  and  credit  union  services 
on  DoD  installations;  and  international  financial  affairs 

Policies  and  procedures  on  the  reporting,  preparation,  and  dissemination  of  statistical  information 

Senior  DoD  official  for  information  resources  management  including  oversight  of  acquisition  and 
use  of  information  technology  and  related  resources  for  business  and  administrative  purposes 

Organizational  analysis  and  management  planning 

DoD  privacy  program  in  compliance  with  the  Privacy  Act  of  1974 

OSD  historical  program  and  DoD  historical  program  coordination 

Policy  guidance  and  coordination  on  matters  of  administrative  support  received  or  provided  by 
DoD  components 

Cost  performance  measurement  systems 

Focal  point  for  selected  acquisition  reports  (SARs)  and  unit  cost  reporting 
Special  studies  and  analyses  related  to  comptroller  responsibilities 

Member  and  Executive  Secretary  of  the  Defense  Resources  Board,  member  of  the  Cost  Analysis 
Improvement  Group,  member  of  the  Defense  Systems  Acquisition  Review  Council,  member  and 
Executive  Secretary  of  the  DoD  Council  on  Integrity  and  Management  Improvement,  and  Chairman 
of  the  Major  Automated  Information  Systems  Review  Council. 

In  addition,  the  ASD(C)  exercises  direction,  authority,  and  control  over 

Defense  Contract  Audit  Agency 
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Washington  Headquarters  Services  (through  the  Deputy  Assistant  Secretary  of  Defense  (Admini¬ 
stration)  who  has  collateral  responsibility  as  Director,  Washington  Headquarters  Services). 

6.4.2.5  Assistant  Secretary  of  Defense  (Manpower,  Installations  and  Logistics)  (ASD(MI&L)>  (DoD 
Directive  5124.1).  Under  the  direction  of  the  Secretary  of  Defense,  the  ASD(MI&L)  is  responsible 
for  the  following  functions: 

Total  force  structure  analysis  as  related  to  quantitative  and  qualitative  manpower  requirements, 
manpower  utilization,  logistics,  readiness,  and  support 

The  allocation  of  the  total  force  structure  among  DoD  components  and  between  the  active  and 
reserve  components  within  the  military  departments 

Civilian  and  military  personnel  management  programs  and  systems,  including  attraction  and 
retention  of  military  personnel;  personnel  utilization;  compensation,  retired  pay,  per  diem,  travel, 
and  transportation  allowances;  civilian  and  military  personnel  career  development,  training,  and 
education;  labor-management  relations;  morale,  discipline,  and  welfare;  and  community  services 

Development  of  civilian  and  military  manpower  programs  and  logistics  programs  to  meet  peacetime 
readiness  and  wartime  sustainability  requirements  of  the  DoD 

Nonappropriated  fund  instrumentalities 

Weapons  support 

Logistics 

Equal  opportunity,  equal  employment  opportunity,  and  DoD  contractor  compliance  with  equal 
employment  opportunity  requirements  in  government  contracts 

Readiness 

Energy 

Installations  management 
Conservation  of  resources 
Economic  adjustment 

Review  and  evaluation  of  the  requirements  of  the  Defense  System  Acquisition  Review  Council 
(DSARC)  weapon  programs  and  proposed  weapon  systems  for  adequacy  of  readiness  goals  and 
resources,  including  manpower,  personnel,  training,  logistics,  installations  support,  reliability, 
maintainability,  and  design  safety. 

In  addition,  the  ASD(MI&L)  exercises  direction,  authority,  and  control  over 

Armed  Forces  Chaplains  Board 

Defense  Logistics  Agency 

Department  of  Defense  Dependents  Schools 

Office  of  Ecnonomic  Adjustment 

DoD  Explosives  Safety  Board 

Defense  Race  Relations  Institute 

Defense  Advisory  Committee  on  Women  in  the  Services 
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6. 4. 2. 6  Director  of  Operational  Test  and  Evaluation  (DOT&E)  (Title  10,  United  States  Code,  Section 
136a)  (DoD  Directive  5141.2).  Under  the  provisions  of  Title  10,  U.S.C.  136a,  and  under  the  direction 
of  the  Secretary  of  Defense,  the  DOT&E  is  the  principal  staff  assistant  and  advisor  to  the  Secretary 
of  Defense  on  OT&E  in  the  DoD  .‘,nd  the  principal  OT&E  official  within  the  senior  management  of 
the  DoD.  In  this  capacity,  the  DOT&E  is  responsible  for  the  following  functions: 

Prescribe  policies  and  procedures  for  the  conduct  of  OT&E  within  the  Department  of  Defense. 

Provide  advice  and  make  recommendations  to  the  Secretary  of  Defense,  and  issue  guidance  to 
and  consult  with  the  heads  of  the  DoD  components  with  respect  to  OT&E  in  the  DoD  in  general, 
and  with  respect  to  specific  OT&E  to  be  conducted  in  connection  with  a  major  defense  acquisition 
program. 

Designate  selected  special  interest  weapons,  equipment,  or  munitions  as  major  defense  acquisition 
programs. 

Develop  systems  and  standards  for  the  administration  and  management  of  approved  OT&E  plans 
for  major  defense  acquisition  programs. 

Monitor  and  review  all  OT&E  in  the  DoD  to  ensure  adherence  to  approved  policies  and  standards. 
Coordinate  operational  testing  conducted  jointly  by  more  than  one  DoD  component. 

Review  and  make  recommendations  to  the  Secretary  of  Defense  on  all  budgetary  and  iinancial 
matters  relating  to  OT&E,  including  operational  test  facilities  and  equipment. 

Initiate  plans,  programs,  actions,  and  taskings  to  ensure  that  OT&E  for  major  defense  acquisition 
programs  is  designed  to  evaluate  the  operational  effectiveness  and  suitability  of  U.S.  military  weapon 
systems. 

Review  and  report  to  the  Secretary  of  Defense  on  the  adequacy  of  operational  test  planning, 
priorities,  support  resources,  execution,  evaluation,  and  reporting  for  major  defense  acquisition 
programs  while  avoiding  unnecessary  duplication. 


6.4.2.7  Director,  Program  Analysis  and  Evaluation  (DP A&E)  (Dor  Directive  5141.1).  Under  the 
direction  of  the  Secretary  of  Defense,  the  DPA&E  is  responsible  for  performing  analyses,  identifying 
issues,  and  evaluating  alternative  programs  fo-  '  e  following  functions: 

Force  review  of  active  and  reserve  components 
Strategic  and  theater  nuclear  forces 

Weapon  systems  and  major  items  of  material,  including  critical  reviews  of  requirements, 
performance,  and  life-cycle  costs  of  current  and  proposed  weapon  systems 

Nuclear  warhead  requirements 
Support  systems 

Deployment  plans  and  overseas  basing  requirements 
Mobility  force  programs  ar.d  prepositioning  plans 
Material  support  programs  and  war  reserve  stocks 
Force  readiness  and  capabilities 

Implications  for  manpower  resources  of  specific  force  structure  plans 
Contingency  plans 
Security  assistance  programs 

Allied  and  foreign  military  requirements  and  capabilities 
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The  DPA&E  also  provides  support  to  the  Secretary  of  Defense  through 
Economic  analyses  and  impact  thereof  on  Defense  programs 

Cost  Analysis  Improvement  Group  leadership  and  support  (in  accordance  with  DoD  Directive 
5000.4). 
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Appendix  6A 

Navy  Acquisition  Process 
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NAVY  ACQUISITION  REFERENCE  DOCUMENTS 
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NAVY  MILESTONE  III  DECISIONS 

•  Approved  for  Full  Production  (AFP) 

•  System  meets  ell  technical  and  operational 
thresholds 

•  ILS  requirements  fully  demonstrated  during 
OTOE 

•  No  additional  development  or  corrective  action 
required 

•  Approved  for  Limited  Production  (ALP) 

•  Aim  at  AFP  for  following  year  AFP/ALP  decision 

•  No  more  than  1  year's  production 

•  COMOPTEVFOR  considers  system  operationally 
effective  and  suitable,  with  clear  plan  and  funding 
for  corrections 

•  Not  approved  for  production 
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SECTION  7 

PLANNING,  SCHEDULING,  AND  ASSESSMENT 


7.1  INTRODUCTION 

7.1.1  References 

There  are  many  formal  planning  documents  that  make  up  the  Navy  RDT&E  planning  process: 
Defense  Guidance  (DG)  documents 
Technology  and  Description  (TAD)  document 
Joint  Long  Range  Strategic  Appraisal  (JLRSA)  document 
Joint  Strategic  Planning  Document  (JSPD) 

Joint  Program  Assessment  Memorandum  (JPAM) 

DON  Policy  and  Planning  Guidance  (DNPPG) 

CNO  Policy  and  Planning  Guidance  (CPPG) 

CNO  Program  Analysis  Memorandum  (CP AM) 

Program  Objective  Memorandum  (POM) 

Department  of  the  Navy  Five-Year  Program  (DNFYP) 

R&D  Plan 

Science  and  Technology  Objective  (STO) 

Operational  Requirement  (OR) 

Marine  Corps  related  documents 
Department  of  the  Navy  RDT&E  Management  Guide 
NAVSO  P  2457 

Navy  System  Management  instructions  used  by  NOSC 
Major  Systems  Acquisition  (DODIR  5000.1) 

RDT&E  Acquisition  Procedures  (OPNAVINST  5000.42B) 

Project  Master  Plan  (NAVMATINST  5200.1  IB) 

Integrated  Logistics  Support  (NAVMATINST  4000.20B) 

Configuration  Management  (NAVMATINST  4130.1A  and  OPNAVINSTs  4130.1  and  4130.2) 
Test  and  Evaluation  (OPNAVINST  3960. 10B) 

Design  Requirements  Baseline  (NAVMATINST  4130. 1  A) 


7.2  GENERAL 

Project  management  is  performed  at  NOSC  by  an  individual  with  the  title  of  “Project  Manager.” 
The  project  manager  has  specific  respoasibility  for  achieving  project  objectives  and  accomplishing  project 
assignments.  Any  manager  who  is  the  cognizant  individual  responsible  for  performance  on  a  project 
is  termed  “project  manager.”  The  extent  that  a  project  manager  becomes  involved  in  managing  a  project 
depends  on  the  size  of  the  project.  Some  of  the  smaller  projects  in  the  Center  may  not  require  the  many 
formal  approaches  for  project  management  that  a  larger  project  may  require.  The  project  manager  should 
tailor  requirements  to  the  needs  of  the  specific  project.  Whenever  possible,  project  managers  should 
use  the  guidelines  as  delineated  in  this  section. 
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The  project  manager  and  the  support  personnel  assigned  to  the  project  provide  for  the  development 
of  project  technical  and  administrative  plans,  procedures,  and  practices  as  necessary  to  facilitate  a  high 
degree  of  technical  and  management  performance.  These  plans  and  procedures  should  mesh  harmoniously 
with  other  Center  practices  and  procedures.  Procedures  should  be  established  and  maintained  for 
obtaining  operational  and  functional  support  from  a  variety  of  resources  such  as  other  departments, 
other  government  activities,  and  independent  contractors.  Project  managers  have  the  responsibility 
for  planning  and  administering  assigned  resources  within  approved  project  and  operational  budgets. 
They  approve  estimates  of  funding  requirements  prior  to  incorporation  into  project  budgets.  Proper 
planning  will  set  the  stage  for  allocation  of  resources  to  the  project  and  ensure  that  plans,  programs, 
budgets,  and  schedules  are  properly  integrated  and  time  phased.  In  addition,  initial  project  planning 
should  consider  the  establishment  of  a  complete  project  chronological  history  that  ensures  the  availability 
of  accurate  information  concerning  all  significant  events  and  decisions  relating  to  the  project,  and  from 
which  the  project  can  be  reconstructed  step  by  step.  The  project  manager  should  be  aware  of  the  current 
status  and  progress  of  the  assigned  project  and  be  able  to  convey  that  information  to  appropriate  Center 
and  higher  command  officials  as  may  be  required.  Technical  content  of  reports  and  quality  of  technical 
data  should  be  reviewed  to  assure  that  high  professional  standards  are  maintained.  Security  precautions 
in  accordance  with  DoD  policy  should  be  strictly  followed  and  enforced. 

Project  managers  assume  responsibility  for  the  management,  planning,  direction,  and  control  of 
project  resources  necessary  for  project  completion.  Project  managers  have  specific  authority  and 
responsibility  for  directing  a  system’s  overall  progress  through  the  conceptual,  validation,  full  scale 
development,  production,  deployment,  and  Fleet  support  phases  of  Navy  weapons  system  acquisition 
and/or  the  completion  of  the  project. 

The  following  documents  should  be  prepared,  as  necessary,  for  each  significant  project: 

a.  Project  functions 

b.  Project  organization  chart 

c.  Organizational  relationship  chart 

d.  Functional  areas  of  responsibility 

e.  Financial  plan 

f.  Milestone  charts 

g.  Network  jilans  and/or  schedules 

h.  Work  breakdown  structure 


i.  Acquisition  plan,  when  applicable 

j.  Value  engineering  plan 

k.  Integrated  logisfics  support  plan 

l.  Configuration  management  plan 

m.  Test  and  evaluation  plan 

n.  Security  plan 

o.  Training  plan 

p.  Safety  plan 

q.  Quality  assurance  plan 
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Data  management  plan 


s. 


Human  engineering  plan 


t.  Project  master  plan 

u.  Project  management  plan 


A  primary  function  of  project  management  is  the  implementation  of  a  useful  planning  and  control 
system.  Control  systems  are  required  to  ensure  that  allocation  of  resources  and/or  acquisition  of  services 
and  equipment  stay  within  the  limits  of  planned  resources.  The  management  planning  and  control 
concepts  discussed  here  have  been  in  existence  for  many  years  in  both  government  and  industrial 
organizations.  These  techniques  provide  for  timely  and  accurate  management  decisionmaking. 


7J  PLANNING  AS  A  TOOL 


Project  plans  are  necessary  to  facilitate  an  organized,  mutually  supportive  set  of  documents  which 
translate  program  authorization,  control,  and  visibility  into  easily  understood  road  maps.  The 
documentation  should  be  designed  so  as  to  enhance  the  ability  of  management  to  react  in  a  timely 
and  favorable  manner  with  regard  to  the  direction  of  the  project. 

The  techniques  used  in  planning  should  consider  elements  such  as  scope  and  complexity  of  the 
project,  available  project  information  and  data,  and  project  commitments.  Also,  the  cost  of  providing 
control  and  reporting  documentation  must  be  considered.  such  control  and  reporting  documentation 
should  be  clearly  specified  in  advance  so  that  budget  requirements  are  included  in  the  overall  project 
funding  requirements. 

Choosing  proper  management  techniques  early  in  project  development  enhances  the  capability 
of  management  to  attain  project  objectives  and  goals.  One  technique  that  is  commonly  used  is  termed 
“management  by  exception.”  Management  by  exception  is  defined  as  comparing  project  plans  and 
status  with  desired  results  for  the  purpose  of  correcting  those  conditions  that  do  not  support  overall 
objectives  and  goals.  By  employing  management  by  exception  principles,  management  is  able  to  spend 
a  greater  amount  of  time  in  areas  that  offer  the  probability  of  attaining  maximum  gain  to  the  project. 
Another  technique  commonly  used  is  termed  “management  by  objectives.”  Management  by  objectives 
is  defined  as  directing  resources  towards  the  accomplishment  of  planned  goals.  The  functions  of 
management  by  objectives  are  planning,  organizing,  staffing,  directing,  and  controlling.  The  attainment 
of  planned  goals  is  contingent  upon  dear,  concise,  and  well  understood  policies  designed  to  enhance 
goals  which  are  important  and  different.  Rewards  will  flow  from  accomplishing  the  extraordinary  goal. 


7.4  PROJECT  MANAGEMENT  PLAN 

The  project  management  plan  should  contain  sections  such  as  introduction,  approach,  project 
management  organizational  structure  and  management  controls,  milestones  and  schedules,  financial 
plan,  and  work  breakdown  structure.  An  example  of  a  project  management  plan  is  offered  in  Appendix 
7A. 
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7.5  INTEGRATED  PLANNING 

Integrated  planning  sessions  are  one  of  the  most  important  tools  available  to  project  management. 
All  project  management  personnel  should  be  trained  in  management  techniques  that  enhance  integrated 
planning.  Periodic  planning  sessions  that  provide  an  open  forum  of  information  flow  through  all 
disciplines  related  to  the  project  are  necessary  during  project  initiation,  development,  test  and  evalua¬ 
tion,  and  acceptance.  Planning  sessions  that  generate  networks  of  activities  and  events,  establish  technical 
sequence  and  flow  constraints,  and  identify  critical  paths  should  be  generated  to  provide  the  basis  for 
allocating  resources  and  planning  realistic  timeframes  for  meeting  project  objectives.  Participants  in 
integrated  planning  sessions  should  be  alert  to  external  constraints  that  may  impact  on  the  timely  com¬ 
pletion  of  the  project.  Networking,  through  planning  sessions,  establishes  the  critical  path  of  the  pro¬ 
ject  and  permits  planning  of  resources  to  improve  or  alleviate  any  identified  slippage  in  the  project 
schedule. 

Task  responsibility  matrices  are  necessary  to  assure  that  all  segments  of  the  project  development 
effort  have  been  effectively  assigned.  The  matrix  should  identify  with  both  technical  personnel 
assignments  and  the  technical  effort  involved  in  the  assignment.  Supportive  documents  such  as  the 
project  organizational  structure  and  the  work  breakdown  structure  should  be  used  in  developing  an 
effective  responsibility  matrix. 

7.6  MILESTONES 
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I 
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Establishing  milestones  for  each  major  segment  of  a  system  under  development  is  termed  milestone 
scheduling.  Milestones  are  similar  to  network  events  in  that  both  reflect  points  in  time.  The  term 
“milestones”  is  used  to  identify  significant  events  that  must  be  accomplished  in  order  to  complete  the 
project  successfully.  Milestone  dates  may  be  established  for  both  start  and  completion  events  of  activities. 
Accomplishment  of  a  significant  event  signifies  a  completed  milestone.  Milestones  may  also  be  portrayed 
on  Gantt  charts,  networks,  and  line  charts. 

The  number  of  milestones  chosen  for  scheduling  and  control  purposes  depends  on  the  size  of  the 
project.  Ordinarily,  at  least  2  weeks  should  separate  milestone  events.  Milestones  are  to  reflect  those 
events  that,  if  not  accomplished  on  schedule,  will  have  significant  impact  on  the  project.  One  of  the 
most  important  functions  of  project  management  is  to  assure  that  milestone  dates  are  negotiated  and 
realistically  established  in  consonance  with  both  internal  and  external  project  requirements. 

The  following  typical  milestone  events  are  provided  as  examples: 

a.  Obtain  project  go-ahead 


b.  Start  functional  specifications 

c.  Functional  specifications  complete 


d.  Start  system  design 

e.  System  design  complete 
«'  Start  procurements 

Start  system  software  development 

h.  Start  fabrication 

i.  Contractor  delivers  hardware 

j.  Fabrication  complete 
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k.  Procurements  received 
!.  Stan  assembly  of  system 

m.  System  software  complete 

n.  System  installation  complete 

o.  Start  test  and  evaluation 

p.  Test  and  evalus.ion  complete 

q.  Start  operations  evaluation 

r.  Operations  evaluation  complete 

s.  Deliver  to  Fleet 

t.  Project  complete 

Appendix  7B  provides  the  format  for  detailed  milestone  reporting,  the  format  for  summary  milestone 
reporting,  and  the  instruction  for  preparation  and  completion  of  milestone  reports.  Milestone  reports 
should  be  monitored  and  maintained  on  a  continual  basis. 


7.7  TECHNICAL  SEQUENCE  AND  FLOW— NETWORKS 

The  network  is  a  planning,  scheduling,  and  project  appraisal  document  which  may  be  used  as 
an  effective  management  control  tool.  Project  uncertainties  such  as  potential  slippages,  schedule  impacts, 
problems  requiring  management  decisions,  and  decision  trade-offs  may  be  identified  by  the  use  of  the 
network.  A  typical  network  is  illustrated  in  Figure  7.1.  In  constructing  networks  as  a  planning  tool, 
the  following  two  principals  should  apply: 

a.  The  network  must  satisfy  the  needs  of  the  project  and  be  flexible  enough  to  incorporate  any 
project  changes  winch  may  occur. 

b.  The  network  must  be  comprehensive  to  the  user,  provide  timely  information  and  be  worth 
the  cost  of  development  and  maintenance. 

The  network  should  contain  the  following  elements: 

a.  Activity— an  incremental  element  of  the  network  that  defines  a  specific  effort  to  be  accomplished 
over  a  period  of  time.  The  activity  is  usually  portrayed  as  a  line  identified  by  the  activity  title. 

b.  Event— a  point  in  time  on  a  network  usually  portrayed  as  a  circle  at  the  beginning  and  end 
of  an  activity.  The  event  may  be  identified  by  a  unique  number. 

c.  Time— elements  of  time  assigned  to  each  activity  usually  portrayed  in  decimal  increments,  i.e., 
1.0  equals  1  week,  2.0  equals  2  weeks,  etc. 

d.  Critical  path— the  longest  path  or  controlling  chain  of  activities  within  a  network  in  which  any 
slippage  will  delay  the  network  end  event. 

Network  logic  display  represents  the  planned  flow  of  activities  and  constraints  as  known  or  perceived 
by  the  personnel  responsible  for  performance.  Identification  of  activities  and  constraints  are  best  defined 
during  integrated  planning  sessions.  Project  managers  should  participate  in  the  integrated  planning 
sessions  to  establish  network  logic.  Time  spans  are  assigned  to  each  activity  when  it  i .  established  that 
the  network  logic  is  a  responsible  portrayal  of  the  activities  to  be  accomplished. 
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Latest  allowable  dates  (TL)  are  determined  by  subtracting  activity  time  spans  from  the  ending 
event  date.  The  longest  path  determined  is  the  critical  path. 

Earliest  expected  completion  dates  (Te)  are  determined  by  adding  time  spans  of  uncompleted 
activities  from  time  now  through  the  ending  activity. 

Slack  is  determined  by  subtracting  the  earliest  expected  completion  date  from  the  latest  allowable 
date  (TL-Te).  The  resultant  positive  or  negative  slack  determines  the  critical  path. 

The  earliest  expected  date  (Te)  may  be  used  to  designate  interim  milestones. 

7.8  WORK  BREAKDOWN  STRUCTURE 

The  work  breakdown  structure  (WBS)  is  defined  as  “a  product-  or  task-oriented  document  which 
depicts  the  end  item  of  a  project,  its  subdivisions,  interrelationships,  and  levels  of  detail.”  A  controllable 
unit  of  work  or  element  in  a  WBS  is  termed  a  work  package.  The  primary  function  of  the  WBS  is 
to  provide  a  systematic,  end  item-oriented  breakdown  of  hardware,  software,  services,  and  other  work 
packages  that  are  required  to  make  up  the  total  system.  Indentures  in  the  WBS  are  defined  as  work 
package  levels,  i.e.,  the  first  level  is  the  system  end  item,  the  second  level  consists  of  work  package 
segments  of  the  end  item,  each  of  which  may  be  further  segmented.  Each  work  package  is  identified 
by  an  element  number.  WBS’s  should  be  built  to  the  level  of  detail  that  most  significantly  depicts  the 
work  to  be  performed.  The  lowest  level  of  detail,  however,  should  be  a  controllable  level  in  areas  of 
performance,  schedule,  and  cost.  Graphic  and  indenture  examples  of  WBSs  are  provided  in  Figures 
7.2  and  7.3,  respectively.  Preparation  of  the  WBS  is  governed  by  MIL-STD-881A.  The  WBS  is  a  valuable 
tool  in  the  development  of  projects,  systems,  equipment,  or  other  material  and  service  items.  Its  use 
is  indicated  for  any  project  which  can  be  broken  down  into  a  significant  number  of  controllable  work 
packages.  The  WBS  is  easily  prepared  manually  for  smaller,  short-lived  projects.  For  larger,  longer 
projects,  automation  is  available  and  recommended. 

7.8.1  Automated  Work  Breakdown  Structure  System 

To  facilitate  WBS  reporting  requirements,  an  automated  WBS  generation  system  is  available.  In 
addition  to  the  planning  function  of  the  WBS,  machine-generated  reports  are  available  to  provide  the 
project  manager  with  timely  information  (on  an  as-required  basis)  of  the  cost  estimates  versus  to-date 
charges  and  obligations  at  all  levels  of  the  structure. 

The  following  reports  in  WBS  format  are  available: 

a.  Report  WBS1  includes  all  levels  of  the  structure.  There  are  three  data  format  options  for  this 
report  (Appendix  7C): 


Option  1 

Option  2 

Option  3 

Estimates 

Estimates 

Estimates 

*  (YTD)  Charges 
***  (MTD)  Charges 

Balance 

*  (YTD)  Costs 
***  (MTD)  Costs 
Encumbrance 

Balance 

**  (ITD)  Costs 
***  (MTD)  Costs 
Encumbrance 
Balance 

*  Year  to  Date 
**  Inception  to  Date 
***  Month  to  Date 

Each  of  the  above  reports  conclude  with  a  recap  by  project  number  as  shown  in  Appendix  7D. 
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b.  Report  WBS2  is  the  same  as  above  except  this  structure  only  shows  the  first  three  summary 
levels  (levels  1,  2,  and  3).  See  Appendix  7E. 

c.  Report  WBS3  is  a  heavily  indented  report  showing  each  element  number  within  the  WBS,  along 
with  the  total  estimate  of  each  work  p;  ~kage  and  the  WBS  work  package  level.  See  Appendix  7F. 

To  initiate  a  WBS  within  the  autonuui  ..  work  breakdown  structure  system,  the  project  manager 
should  direct  the  preparation  of  the  WBS,  ensuring  that  the  WBS  worksheet  shown  in  Appendix  7G 
is  prepared  in  accordance  with  the  instructions  included  with  it.  Completed  forms,  along  with  instructions 
as  to  which  report  options  and  what  reporting  frequency  is  desired,  may  be  submitted  to  data  processing 
for  action. 

A  WBS  element  number  should  be  established  for  each  work  package  of  the  WBS.  Figure  7.3 
provides  two  options  that  may  be  used  in  structuring  a  WBS  element  numbering  system. 


7.8.2  WBS  Element  Description  Record 

In  conjunction  with  the  WBS,  a  WBS  Element  Description  Record  as  formatted  in  Appendix  7H 
should  be  filled  out  for  each  element  to  a  practical  level  in  the  WBS.  Instructions  for  preparing  the 
WBS  Element  Description  Record  are  also  included.  These  records  should  be  maintained  as  an  integral 
part  of  project  plans. 


7.9  PROJECT  PLANNING  RANGE 

Adherence  to  directives  is  a  critical  part  of  project  management.  To  this  end,  a  project  management 
questionnaire  has  been  developed  to  aid  the  project  manager  in  determining  a  broad  range  of  directive 
subjects  that  require  consideration  during  the  project  development  phase.  The  questionnaire  covers 
such  subjects  as  project  authorizations,  funds,  project  management,  project  documentation, 
procurements,  systems  engineering,  data  management,  integrated  logistics  support,  product  assurance, 
test  and  evaluation,  security,  and  safety.  The  project  management  questionnaire,  as  delineated  in 
Appendix  71,  is  provided  as  a  guide  to  the  management  decision  process. 


7.10  SCHEDULES 


7.10.1  Bar  Charts 

Bar  charts  are  used  as  a  visual  indicator  depicting  size  variations  when  compared  to  a  given  scale. 
They  provide  a  relatively  simple  visual  aid  to  the  project  manager  and  function  as  a  management  tool 
for  communicating  status  and/or  decisionmaking. 

7.10.2  Gantt  Charts 

Gantt  charts  portray  performance  or  output  related  to  time  and  are  commonly  used  as  master 
schedules,  progress  charts,  and  milestone  charts.  Gantt  charts  were  first  developed  by  Henry  L.  Gantt 
early  in  the  twentieth  century.  Since  then,  many  variations  have  been  used  successfully.  The  primary 
purpose  of  Gantt  charts  is  to  convey  schedule  conditions  and  status  to  the  manager.  They  are  also 
used  to  track  actual  completion  data. 
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A  series  of  activities  is  portrayed  on  a  Gantt  chart  by  the  use  of  horizontal  bars  under  a  dateline. 
The  area  under  a  dateline  is  commonly  referred  to  as  the  plotting  plan.  Bars  or  lines  may  be  color 
coded  to  signify  status  and/or  progress.  Color  coding  provides  a  ready  means  for  the  manager  to 
determine  the  status  of  ongoing  tasks. 

Constraints  are  portrayed  on  the  plotting  plan  by  the  use  of  vertical  dash  lines.  Arrows  are  used 
to  signify  direction  of  constraints.  Dash  lines  used  in  a  horizontal  direction  signify  unscheduled  time. 
Specific  points  in  time  or  events  are  indicated  by  the  use  of  small  symbols  such  as  triangles,  squares, 
etc.  Legends  are  placed  just  below  and  to  the  right  of  the  plotting  plan. 

Figure  7.4  is  provided  as  an  example  of  a  master  schedule  illustrating  the  Gantt  chart  concept. 
Schedule  sequence,  status,  and  progress  should  be  portrayed  in  such  a  manner  that  it  is  readily  understood 
by  the  reader. 

7.10.3  Line  Charts 

Line  charts  plot  the  movement  of  one  or  more  quantities  over  a  period  of  time.  Time  units  are 
shown  horizontally  and  quantities  are  shown  vertically.  Schedule  versus  actual  information  may  be 
measured  by  plotting  actual  data  at  specific  points  in  time  during  the  life  of  the  schedule. 


7.11  PROJECT  PROGRESS  REPORTS 

7.11.1  General 

Progress  reports  have  been  prepared  and  submitted  to  sponsors  in  many  different  formats  over 
the  past  years.  Appendix  7J  provides  a  project  progress  report  format.  Status  that  is  pertinent  to  overall 
project  management  and  of  specific  interest  to  the  sponsor  is  reflected  in  the  progress  report.  Conveyance 
of  internal  details  and/or  milestones  that  are  not  significant  are  to  be  avoided. 

7.11.2  Objectives 

The  standard  progress  report  format  is  designed  to  provide  a  tool  for  project  reviews  and  assessment. 
To  this  end  the  project  progress  report 

a.  Provides  for  continuity  of  status  reporting 

b.  Provides  a  better  understanding  of  project  status,  progressions,  problems,  and  planned  corrective 
actions 

c.  Facilitates  rapid  and  understandable  review  by  higher  management 

d.  Provides  a  common  outline  for  historical  cataloging 

e.  Allows  for  comparative  analysis  data  within  and  between  projects. 

7.11.3  Procedure 

Reporting  of  financial  data  through  the  project  progress  report  is  contingent  upon  specific 
requirements  of  both  the  project  manager  and  the  sponsor.  Appendix  7J  also  provides  the  instruction 
for  preparation  and  completion  of  the  progress  report. 


Figure  7.4.  Master  schedule  (Gantt  chart  example). 


7.12  PROCUREMENT  PLANNING 


7.12.1  Contraei/Purchase  Order  Planning 

Procurement  planning  is  defined  as  a  series  of  decisions  directed  to  the  integration  of  procurement 
with  technical  and  financial  plans  during  the  acquisition  cycle.  The  planning  process  must  be  performed 
well  in  advance  of  procurement  initiation  in  order  to  foresee  potential  procurement  problems.  The 
planning  process  applies  to  all  major  and  minor  procurements.  Several  directives  are  available  with 
regards  to  procurement  planning.  They  are  SECNAVINST  4200.31,  NAVMAT1NST  4200.30D, 
NAVMAT1NST  4200.49,  NAVMATINST  4200.50C,  NAVMATINST  4200.52,  NAVMATINST 
4200.54,  NAVMATINST  4200.55,  OPNAVINST  5000.42B,  SPAWARINST  4200.6D,  NAVMATINST 
5000.29A,  and  FAR  Section  1,  Part  21,  Appendix  J. 

The  responsibility  for  procurement  planning  lies  with  the  project  manager.  The  degree  of  planning 
required  for  procurements  depends  to  a  great  extent  on  the  dollar  amount  of  the  procurement.  The 
Contract  Division  is  responsible  for  providing  expertise  in  the  area  of  procurements  to  all  of  the  technical, 
scientific,  and  management  personnel  at  NOSC.  The  project  manager  has  the  responsibility  for  reviewing 
and  taking  responsibility  for  procurement  requirements  being  processed  in  support  of  the  project. 

The  planning  of  procurements  is  interrelated  with  early  requirement  definition  accomplished  during 
the  exploratory  and  advanced  development  stages  of  system  development.  Determination  of  hardware 
and  software  requirements  of  a  system  is  an  integral  part  of  the  system  engineering  process.  Plans  for 
procurement  actions  should  be  formed  during  development  of  functional  and  system  specifications. 

The  goal  of  advanced  procurement  planning  is  to  obtain  a  successful  system,  in  a  timely  manner, 
at  the  lowest  total  cost  to  the  Navy.  Realistic  milestones  with  adequate  lead  times  should  be  depicted 
on  a  graphic  timetable  display.  This  scheduling  action  should  be  accomplished  well  in  advance  of 
procurement  package  preparation.  Procurement  milestones  should  be  interrelated  as  part  of  all  other 
activities  of  the  system  development  in  order  to  determine  the  most  critical  areas  with  regards  to  lead 
time.  Graphic  displays,  such  as  the  Gantt  chart  in  Figure  7.4,  may  be  used  in  the  procurement  planning 
process. 

7.12.2  Acquisition  Plans  (APs) 

Acquisition  plans  are  formal  documents  prepared  for  the  purpose  of  defining  major  procurement 
programs  during  the  life  cycle  of  systems  development.  The  schedule  impact  of  long  lead  time  major 
procurements  is  of  primary  concern  to  project  managers.  To  this  end,  project  managers  should  ensure 
that  approaches  and  requirements  for  acquisition  plans  are  considered.  Acquisition  planning  may  be 
defined  as  a  series  of  decisions  directed  to  the  integration  of  procurement,  technical,  and  financial 
plans  during  the  project/weapon  systems  acquisition  cycle.  Federal  Acquisition  Regulations  (FAR),  Part 
7,  addresses  acquisition  plans.  Project  managers  should  contact  the  Supply  Department  for  guidance 
in  preparing  acquisition  plans. 
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Appendix  7A 

Model  Project  Management  Plan 
(See  subsection  7.4) 
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SECTION  1 


INTRODUCTION 


1 . 1  PURPOSE 


The  purpose  of  this  Project  Management  Plan  is  to  present  the  development 

approach  for  the  _ (project) _  and  to  define  the  management  tools  and 

resources  that  'ill  be  utilized.  The  plan  is  logically  divided  into  six 
sections  covering  all  aspects  of  NOSC  project  management: 


Section 

1 

2 

3 

4 

5 

6 

1.2  TASK  ASSIGNMENT 


Title 

Introduction 

Approach 

Project  Management 
Milestones  and  Schedules 
Financial  Plan 
Work  Breakdown  Structure 


The  _ (project) _  was  established  in  response  to  (RCO,  etc.)  on 

_ (date) _ .  The  essential  elements  of  the  Project  are  to  conduct 

design,  development,  teest  and  evaluation  of  _ (project) _ . 

The  Principal  Development  Activity  (PDA)  for _ (project) _  is 

_ 'sponsor) _ .  The  Naval  Ocean  Systems  Center  (NAVOCEANSYSCEN, ,  San 

Diego,  California,  has  been  designated  the  Performing  Activity  (PA)  by 
_ (sponsor) _  task  assignment  letcer  _ (date) _ . 

1.3  PROBLEM  DEFINITION  AND  BACKGROUND 

Describe  the  problem  and  circumstances  that  led  to  the  requirement  for 
this  project.  Also,  generally  define  the  historical  background. 
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1 .4  OBJECTIVES 


Define  the  objectives  of  the  project  and  the  expected  results  of  the 
effort.  (The  objectives  may  be  to  develop  a  feasibility  model  and  then  an 
advanced  development  model  (ADM)  which  will  finally  lead  to  an  engineering 
development  model  ( EDM ) ) . 


1.5  GENERAL  SYSTEM  DESCRIPTION 


In  general  terms,  supported  by  a  block  diagram,  describe  the  system. 
(One  or  two  paragraphs). 


SECTION  2 


APPROACH 

2.1  GENERAL 

This  section  defines  the  approach  to  be  taken  in  solving  the  problem 
defined  in  paragraph  1.3.  It  includes  the  development  approach  which  covers 
such  areas  as  planning,  design,  fabrication,  and  test  and  evaluation.  This  is 
then  followed  by  the  technical  approach  which  goes  more  into  the  technical 
details. 

2.2  DEVELOPMENT  APPROACH 

Explain  who  will  develop  each  objective  (ADM/EDM),  what  tests  will  be 
performed,  including  use  of  COMOPTEVFOR  and/or  other  agencies.  Also  include 
development  of  specifications  and  the  procurement  packages.  A  general  tech¬ 
nical  sequence  and  flow  diagram  may  be  used  to  support  the  text;  e.g., 

Research-Exploratory  Advanced  Development  Engineering 

Development  Development 

Sys.  Dev. 

Sys.  Engr. 

Documen  ta  ti on 
Software 
T&E 

This  section  may  be  expanded  to  include  a  brief  description  of  the  proposed 
technical  approach. 
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2.2.1  Pre-  Task  Planning 


lne  detailed  planning  and  definition  of  tasks  and  responsibilities  shall 
be  accomplished  as  follows: 


b.  Contractual  specifications  and  procurement  package  data  identified  by 
the  finalized  EM  definition  shall  be  prepared  prior  to  entering  the  design  and 
fabrication  phase. 


2.2.2  Design  and  Fabrication 


Quality  assurance  shall  be  obtained  by  means  of  inspection  and  testing  of 
components  a» A  subassemblies  prior  to  assembly  integration. 


2.2.3  Test  and  Evaluation 
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a.  Summary  Work  Breakdown  Structure  (WBS)  should  be  prepared  and 
included  in  Section  6.  In  conjunction  with  the  preparation  of  this  WBS,  WBS 
Element  Description  Records  should  be  prepared  and  maintained  as  an  integral 
part  of  this  plan.  These  records  shall  be  used  for  negotiation  with  the  re¬ 
sponsible  activities  to  finalize  the  detailed  tasks  and  responsibilities  to  be 
delegated. 


c.  Test  planning  shall  be  implemented  relevant  to  technical  evaluation 
requirements. 


Factors  to  be  considered  in  the  EM  design  are  addressed  in  the  EM  defini¬ 
tion.  Design  development  shall  be  guided  by  continuing  in-house  design 
reviews  and  by  formal  design  reviews  as  scheduled  in  Section  4.  As  occurring 
design  reviews,  design  requirements  shall  be  modified  on  the  basis  of  updated 
evaluations  or  changes  in  relative  criticality  disclosed  during  these  reviews. 


Tests  and  evaluations  are  to  be  conducted  as  reflected  in  the  WBS.  Test 
plans  and  procedures,  with  subsequent  test  results,  shall  be  submitted  for 
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To  provide  a  smooth  transition  for  entering  into  engineering  development, 
data  evolving  from  each  event  in  the  scheduled  program  shall  be  collected  by 
the  project.  These  data  shall  be  used  in  the  preparation  of  descriptions  of 
services  and  materials  for  procurement  packages  to  be  used  in  soliciting 
invitations  for  bids  in  competitive  procurement. 

2.3  TECHNICAL  APPROACH 


integration  into  the  overall  support  test  plan  and  engineering  test  report  as 
appropriate . 

2.2.4  Preliminary  EDM  Procurement  Preparation 


Write  a  comprehensive  narration  of  the  system  and  the  technical  approach 
as  to  development  of  the  system. 


SECTION  3 


PROJECT  MANAGEMENT 

3.1  GENERAL 

The  Principal  Development  Activity  (PDA)  for  (project)  is  (sponsor). 
NAVOCEANSYSCEN  is  the  Performing  Activity  for  development  and  management  of 
the  (project).  Specific  responsibility  in  fulfillment  of  project  objectives 
are  assigned  to  NAVOCEANSYSCEN  by  (sponsor)  in  the  form  of  (refer  to  sponsor 
authorization).  This  section  identifies  the  organizational  structure  and 
management  controls  employed  in  fulfillment  of  the  objective. 

3.2  ORGANIZATION 

Figure  3-1  depicts  the  relationships  among  organizations  involved  in  the 
(project).  NAVOCEANSYSCEN,  Code  (managing  code)  is  the  (project)  and  is 
responsible  for  project  management.  NAVOCEANSYSCEN  technology  codes  will 
accomplish  specified  work  in  support  of  the  (project)  development  under  spe¬ 
cific  work  assignments.  Other  activities  and  contractors  will  be  tasked  as 
required. 

3.3  MANAGEMENT  CONTROL  SYSTEM 

Management  controls  will  be  exercised  by  the  (project)  over  task  assign¬ 
ments,  manpower  expenditures,  cost,  and  scheduling.  These  controls  will  be 
keyed  to  specific  elements  of  a  Work  Breakdown  Structure  (WBS)  constituting 
the  bases  for  task  identification  and  baseline  configuration  identification. 
The  WBS  is  described  in  Section  6. 

3.3.1  Task  Assignments 

Tasks/Work  packages  as  identified  on  the  WBS  Element  Description  Record 
will  be  assigned  to  appropriate  Project  Managers.  Manpower  and  funding  will 


EXAMPLE:  only  show 
cognizant  codes  and 


Figure  3-1 

Organizational  Chart 


be  allocated  to  these  tasks  for  subsequent  correlation  with  expenditure  rates 
tabulated  by  the  cognizant  NAVOCEANSYSCEN  Project. 

3.3.2  Cost  Control 

The  plannned  expenditure  rate  for  (project)  is  shown  in  Figure  3-3  for  FY 

( _ ).  Cumulative  costs  identified  by  weekly  MIS  printouts  for  each  task 

will  be  correlated  with  the  projection.  Using  this  method,  the  effects  of 
major  program  expenditures  and  unexpected  trends  in  the  expenditure  rate  will 
be  readily  determined,  permitting  program  adjustments  or  corrective  action  to 
be  taken.  The  financial  plan  by  WBS  element  is  given  in  Section  5. 
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Figure  3-3  Expenditure  Profile 
3.3.3  Manpower  Expendi ture 


The  cumulative  total  manhours  expended  against  each  activity  and/or  work 
package  will  be  tabulated.  The  rate  of  expenditure  will  be  correlated  with 
the  anticipated  rate  shown  on  the  Manpower  Loading  Chart  in  Table  3-1 . 

3.3.4  Milestone  Control 

The  (project)  milestones  will  be  monitored  and  controlled  by  periodic 
reviews  of  the  milestone  lists  in  Section  4.  Progress  for  each  activity  will 
be  correlated  to  these  lists  permitting  corrective  action  to  be  taken  as 
required. 

3.3.5  Design  Reviews 

Design  reviews  will  be  held  periodically  with  all  participating  project 
organizations  and  MAVOCEANSYSCEN  technical  codes.  The  reviews  are  significant 
as  a  medium  of  assuring  technical  compatibility  at  component  interfaces. 
Design  reviews  direct  management  attention  to  the  status  of  accomplishment  and 
significant  technical  or  management  problems.  System  Preliminary  Design  Re¬ 
views  (PDRs)  and  Critical  Design  Reviews  (CDRs)  will  be  held  as  required,  with 
all  cognizant  participants  and  the  sponsor. 


3.4  MANAGEMENT  REPORTS 


3.4.1  Monthly  Reports 

Monthly  reports  of  status  will  be  submitted  to  (sponsor)  on  appropriate 
NAVOCEANSYSCEN  project  progress  report  formats.  The  reports  will  include  the 
status  of  milestone  accomplishment,  the  status  of  funds  and  significant  events 
occurring  during  the  month. 

3.4.2  Conference  Reports 

Narrative  reports  will  be  submitted  of  formal  and  informal  conferences 
with  staff  personnel  or  other  commands. 

3.4.3  Design  Review  Reports 

Reports  of  Design  Review  Meetings  will  be  made  and  furnished  to  (sponsor) 
and  all  supporting  project  organizations  and/or  NAVOCEANSYSCEN  codes. 

3.5  SYSTEM  ENGINEERING 

3.5.1  System  Definition 

The  primary  tasks  of  system  engineering  during  Advanced  Development  in¬ 
volve  derivation  of  an  optimum  equipment  configuration  and  software  control 
mechanisms  that  will  achieve  the  capability  of  the  system  to  search,  acquire, 
track  and  communicate.  The  basic  system  components  and  functional  area  per¬ 
formance  requirements  have  been  defined  and  are  documented  in  the  Type  A 
System  Specification.  This  phase  of  system  engineering  will  culminate  with 
preliminary  test  results  upon  completion  of  subsystem  bench  tests. 

3.5*2  System  Optimization 

As  system  testing  progresses  from  bench  tests  through  final  testing,  data 
will  be  obtained  that  will  prove  the  functional  design  integrity  or  indicate 
areas  where  trade-offs  are  necessary.  Reconfiouration  studies  will  be 


conducted  as  appropriate  during  the  period  following  these  tests.  The  results 
will  permit  finalization  of  the  system  and  critical  item  specifications  for 
the  EDM  procurement  package.  During  Engineering  Development,  the  system 
engineering  function  will  be  expanded  to  include  all  aspects  of  reliability, 
maintainability  and  support  required  by  the  operational  configuration. 

3.6  CONFIGURATION  MANAGEMENT 

Formal  configuration  management  will  be  implemented  at  the  beginning  of 
the  Engineering  Development  Phase.  It  is  desirable  to  maintain  design 
flexibility  until  the  optimum  configuration  has  been  established.  Appropriate 
control  will  be  exercised  by  the  (project)  to  assure  adequate  documentation  of 
the  design  and  translation  of  pertinent  data  to  the  final  system  and  critical 
item  specifications  for  the  EDM.  Planning  for  configuration  management  will 
be  undertaken  concurrent  with  the  preparation  of  the  EDM  procurement  package. 


7-3! 


■  j.  *.  • » » . 


$ 


SECTION  4 


MILESTONES  AND  SCHEDULES 


4.1  GENERAL 


The  milestones  and  schedules  for  the  (project)  will  be  included  in  this 
section;  each  milestone  should  be  keyed  to  the  related  WBS  element  number. 
(See  Section  6)» 

4.2  PROJECT  MILESTONES  AND  SCHEDULES 

Development  of  the  (project)  involves  accomplishment  of  specific  tasks 
which  are  sometimes  dependent  on  completion  of  previous  tasks.  The  major 
tasks,  their  relationship  to  each  other,  and  the  schedule  should  be  shown  in 
Figure  4-1,  Time  Dependency  Chart.  All  major  milestones  should  also  be 
identified  on  this  chart.  (Table  4-1  is  a  list  of  the  (project)  milestones 
and  Table  4-2  is  a  list  of  deliverables. ) 


9 


EXAMPLE 


Feasibility  Study  Checkout 

(WBS  1.1.3)  (WBS  3.4.2) 


Design 
(WBS  1.1.6) 


\  Sys.  Engr 


(WBS  6.1.1) 


Time - > 


Prepare  a  flow  chart  showing  dependencies,  WBS,  and  task 
descriptions.  This  chart  may  be  a  large  foldout  page. 


Figure  4-1.  Time  Dependency  Chart 

NOTE:  This  should  be  one  of  the  first  tasks  accomplished  by  the 
Project  Manager. 


Figure  4-1.  Milestones 
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Table  4-2  List  of  Deliverables 


WBS 

ELEMENT 

NUMBER 

DELIVERABLE 

TYPE  OF 
DELIVERABLE 

7.2.7 

EM  Definition 

Preliminary 

6.1.2 

Program  Plan 

Final 

7.2.7 

EM  Definition 

Final 

7.2.7 

EM  Development  Support  Test 
Plan 

Final 

5.3.1 

Installati  j-'  Plan 

Final 

6.1.2- 

7.3 

Program  Plan  (Updated) 

Final 

7.2.5 

System  Engineering  Test 

Report 

Final 

7.2.6 

EDM  Spec  and  Data  Package 

Final 

DATE  OP 
DELIVERABLE 


EXAMPLE 


#  | 
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SECTION  5 


FINANCIAL  PLAN 

5.1  FINANCIAL  REQUIREMENTS 

The  total  cost  for  _ (project) _  is  shown  in  Table  5-1.  Cost  for 

major  activities  and  lower  work  elements  (level  3)  for  each  FY  is  shown  in 
Table  5-2.  Labor  and  overhead,  major  procurement,  material  and  travel  costs 
from  the  individual  tasks  (level  4)  identified  in  the  Work  Breakdown  Structure 
of  Section  6  were  utilized  in  the  preparation  of  these  cost  summary  figures. 

Major  procurement  and  material  costs  can  be  summarized  by  subsystem  in 
subsequent  tables.  Corresponding  level  3  Work  Breakdown  Structure  line  item 
numbers  can  be  shown  in  the  major  procurement  and  material  summary  tables  to 
permit  cross  reference  to  the  corresponding  tasks  in  the  WBS. 

5.2  COST  CONTROL 

The  NAVOCEANSYSCEN  Management  Information  System  (MIS)  will  be  used  to 
report  and  document  cost  control.  This  MIS  consists  of  computerized  reports 
of  all  expenditure  (labor,  material,  and  travel)  and  will  be  delivered  to  the 
project  manager  on  a  weekly  basis.  The  reports  will  be  keyed  to  the  WBS  (see 
<3®tail  Section  6),  The  project  manager  will  correlate  technical  progress  to 
project  milestones  and  financial  status  on  a  regular  basis  to  assess  total 
project  status.  With  this  information,  the  project  manager  will  exercise 
effective  cost  control  of  the  project. 

5.3  FINANCIAL  REPORTING 

A  summary  of  project/subsystem  financial  status  will  be  delivered  to  the 
program  manager  (sponsor)  on  a  quarterly  basis. 


5.4  COST  ANALYSIS 
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Work  breakdown  structure  (wbs) 


SECTION  6 


WORK  BREAKDOWN  STRUCTURE 


6.1  INTRODUCTION 


The  major  (project)  management-control  tool  will  be  the  work  breakdown 
structure  (WBS).  The  WBS  is  a  product-oriented  device  composed  of  hardware, 
software,  services,  and  other  work  tasks  which  result  from  project  engineering 
efforts  during  the  development  and  production  of  a  project.  The  WBS  system 
enables  a  project  manager  to  logically  breakdown  the  overall  task  into  smaller 
workable  segments  that  can  individually  be  implemented,  managed,  and 
controlled  whereupon  completion,  the  total  task  will  be  accomplished.  Each 
task  in  this  system  is  assigned  a  WBS  element  number  which  can  be  controlled, 
by  ADP,  as  to  status,  costs,  and  recording. 

6.2  (PROJECT)  WORK  BREAKDOWN  STRUCTURE 

Figure  6-1  displays  the  product  to  be  developed  and  relates  the  elements 
of  work  to  be  accomplished  to  each  other  and  to  the  end  product.  Table  6-1  is 
an  indentured  form  of  the  WBS  which  enables  easy  revising  and  updating.  WBS 
Element  Description  Records  will  be  prepared  for  each  work  package  in  the  WBS, 
indicating  milestones,  deliverables,  and  responsibilities  for  that  particular 
work  pac’  \ge.  (See  Figure  6-2). 
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TABLE  6-1 


WORK  BREAKDOWN  STRUCTURE 

LEVEL  LEVEL  LEVEL  LEVEL 

12  3  4 

1 . 0  PROJECT 

2 . 0  SYSTEM  PROJECT 
MANAGEMENT 

2 . 1  PROJECT 

2 . 1  MANAGEMENT 

2.1.1  PROGRAM  PLAN 

2.1.2  CONFIG .  MANAGEMENT 

2.1.3  QUALITY  ASSURANCE 

2.1.4  COST  &  SKED  MGNT 

2.1.5  DATA  MANAGEMENT 

2.1.6  I.W.A, .'S  &  CONTRACT 

2.1.7  REPORTS  &  BRIEFING 

2.2  SYSTEM  ENGINEERING 
&  MANAGEMENT 

2.2.1  SYSTEM  EFFECTIVENESS 
(RMAILS) 

2.2.2  SPECIFICATIONS  (A&B) 

2.2.3  SYSTEMS  INTEGRATION 

2.2.4  SYSTEM  DESIGN 
ENGINEERING 

2.2.5  HUMAN  FACTORS 

2.2.6  SECURITY 

3 . 0  INJECTION  TERMINAL 
SUBSYSTEM 

3 . 1  INTEGRATION  & 

ASSEMBLY 

3.1.1  ASSY/SUB-ASSY 

EXAMPLE  INTERFACES 

3.1.2  ELECTRICAL  INTE¬ 
GRATION 

3.1.3  MECHANICAL  INTE¬ 
GRATION 

3.2  COMPUTER  PROGRAMS 

3.2.1  EXECUTIVE  ROUTINES 

3.2.2  FUNCTION  ROUTINES 

3.2.3  DIAGNOSTIC  &  MAIN¬ 
TENANCE  ROUTINES 

3.2.4  I/O  CONTROL  ROUTINES 

3.3  I/O  SUB-ASSEMBLIES 

3.3.1  MSG  ENTRY  DEVICE 

3.3.2  DISPLAY 

3.3.3  HARD  COPY  DEVICE 

3.3.4  CONTROL 

3.3.5  MMPS  MESSAGE  OUTPUT 

3.3.6  SELF-TEST 

3.4  ADP  SUB-ASSEMBLIES 

3.4.1  ARITHMETIC  SUB-ASSY 

3.4.2  MEMORY 

3.4.3  EXEC.  CONTROL 

3.4.5  I/O  CONTROL 
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WBS  ELEMENT  DESCRIPTION  RECORD 


ENGINEERING  TASK  DESCRIPTION 


j  1.2. 3. 4  INTEGRATED  LOGISTICS  SYSTEM  (ILS)  SUPPORT 

| 

Monitor  ILS  work  performed  under  contract.  Review  the  ILS 
plans  of  the  various  segment  and  subsystem  managers  for  compatibility 
with  the  over-all  program  ILS  plan. 

(1)  Prepare  an  analysis  of  the  T&E  Plans 

(2)  Provide  inputs  to  the  Configuration  Management  Plan, 

Project  Base  Line,  System  Specifications,  Technical  Interface 
Specifications,  Peripheral  System  Interface  Specifications,  T&E  Master 
Plan,  System  Test  Plan  and  COMSEC  Area  Plan. 

%CB? 

I 

i 

I 

i 

i 


» 

[  EXAMPLE 


i 

Figure  6-2  WBS  Element  Description  Record  (1  of  2) 


Appendix  7B 


Milestone  Reporting 
(See  subsection  7.6) 
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MILESTONE  REPORT 
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MILESTONE  REPORT  -  DETAIL 


NO. 


MILESTONE  IDENTIFICATION 


WEEK  ENDING 
3/ 


PROJECT 

4/ 


MILESTONE  CATE 


CHECK  ONE 


SCHED  I  REVISED  ACTUAL 


MADE  MISSED 


CURRENT 

WEEK 

MISSED 


5/ 


6/ 


7/ 


8/ 


9/ 


10/ 


11/ 


12/ 


13/  TOTALS 


DISCUSS  MILESTONES  MISSED  (INCLUDE  REASONS.  EFFECT  ON  PROJECT.  REMEDIAL  ACTION 
TAKEN,  AND  WHEN) 


14/ 


SIGNATURE 

DATE 

15/ 

16/ 
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Instruction  for  the  Preparation  and  Completion 
of  Milestone  Reports 

Applicable  blocks  on  the  milestone  report  will  be  completed  as  follows: 


Block 

Entry  Item 

Instructions 

1. 

From 

Provide  the  code  of  the  cognizant  project 
manager,  as  applicable. 

2. 

To 

Provide  the  code  of  activity  that  the 
milestone  report  is  being  directed  to. 
Usually  this  is  the  project/division 
office/sponsor. 

3. 

Week  Ending 

Enter  the  week  ending  date  covered  by  the 
milestone  report. 

4. 

Project 

Enter  the  four  digit  project  number. 

5. 

No. 

Enter  sequential  numbers  as  required. 
This  field  serves  to  identify  the  mile¬ 
stone  by  a  single  reference  number. 

6. 

Milestone/Identification 

Enter  the  milestone  names  listen  in 
sequence  by  earliest  date  first. 

7. 

Schedule 

Enter  the  schedule  date  that  the  mile¬ 
stone  is  to  be  accomplished. 

8. 

Revised 

Enter  revised  dates,  if  applicable.  This 
block  will  be  used  only  when  scheduled 
milestone  dates  require  revision  in  con¬ 
sonance  with  project  objectives. 

9. 

Actual 

Enter  the  actual  completion  of  accomp¬ 
lishment  date  of  the  milestone. 

10. 

Check  One  -  Made 

Enter  a  check  mark  if  milestone  was  made. 

11. 

Check  One  -  Missed 

Enter  a  check  mark  if  milestone  was  missed. 
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Block 


12. 


13. 


14. 


15. 

16. 
17. 


18. 


19. 


20. 

21. 

22. 

23. 

24. 

25. 


26. 


27. 


28. 

29. 


Entry  Item 

Current  Week  -  Missed 


Instructions 


Enter  a  check  mark  if  milestone  missed 
Uiing  the  current  reporting  week. 


Totals 


Enter  the  total  count  of  check  marks  in 
bJ.ock  columns  10,  11,  12. 


Discuss  Milestones  Missed 


Provide  reasons,  effects  on  project,  reme¬ 
dial  action  taken  or  to  be  taken,  and  when. 


Signature 

Date 

From 


Project  manager  enters  signature. 
Self  explanatory. 


Provide  the  code  number  from  which  the 
milestone  report  is  being  directed. 


To 


Provide  the  code  number  to  which  the  mile¬ 
stone  report  is  being  directed. 


Week  Ending 


Enter  the  week  ending  date  covered  by  the 
detail  milestone  reports. 


Project 
Project  Name 
Schedule 
Made 
Missed 

Current  Week  Missed 


Enter  the  project. 

Enter  the  name  of  the  project. 

Enter  the  number  of  milestones  scheduled. 
Enter  the  number  of  milestones  made. 

Enter  the  number  of  milestones  missed. 


Enter  the  number  of  milestones  missed  for 
the  current  week  only. 


Total 


Enter  totals  for  each  of  the  block  columns 
22,  23  and  24. 


Discuss  Milestones  Missed 


Provide  reasons,  effect  on  project,  reme¬ 
dial  action  taken  or  to  be  taken,  and  when. 


Signature 

Date 


Enter  authorized  signature. 
Self  explanatory. 
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Report  WBS1  Options 
(See  subsection  7.8.1) 
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Report  WBS2 
(See  subsection  7.8.1) 
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Appendix  7F 

Report  WBS3 
(See  subsection  7.8.1) 
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Appendix  7G 

The  Work  Breakdown  Structure  (WBS) 
Worksheet 

(See  subsection  7.8.1) 
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Instruction  for  the  Preparation  and  Completion 
of  Work  Breakdown  Structure  Worksheets 


Block  Entry  Item 

1,  2  WBS  Number 

3,  4  Project  Title 

5  Level  1  Element  Title 

6  Element  Number 

7 .  Level  Number 

8 .  Element  Title 

9  Job  Order  Number 

10  Name 
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Instruction 


Enter  an  arbitrary  number  to 
distinguish  this  WBS  from  any 
other.  This  number  may  be 
assigned  by  the  project  manager. 
Input  the  number  in  both  blocks 
a  and  2.  Fill  out  only  on 
page  1,  not  necessary  on  succeed¬ 
ing  pages. 

Enter  title  of  project  to  include 
two  lines.  The  title  will  be 
used  as  a  page  heading  on  all 
reports  for  this  WBS.  Each  line 
should  be  centered.  Fill  out  on 
page  1  only,  not  necessary  on 
succeeding  pages. 

Enter  the  title  of  level  1  (left 
justified) .  Fill  out  on  page  1 
only,  not  necessary  on  succeeding 
pages . 

Enter  the  element  number  (left 
justified) .  Input  with  decimal 
points,  i.e.,  1.4.13.6.3,  2. 3. 5. 2 
etc. 

Enter  level  of  this  element. 

Input  as  02  for  level  2,  06  for 
level  6,  etc. 

Enter  the  element  title  (left 
justified) . 

Input  a  job  order  number  for 
detail  elements  as  required.  If 
more  than  one  job  order  number  is 
associate  with  a  detail  element, 
input  a  duplicate  line  for  each 
(left  justify) . 

Enter  the  name  of  the  person 
filling  out  forms. 


«rx  m^K.U3CW~x^n_k'x  inunur'F  m  nji  n  w  hm tl*  rj>  ■  «  ■  _m  -  >  *vjs  ajp  cm  1-—  -v»  rw* 


Appendix  7H 


The  Work  Breakdown  Structure  (WBS) 
Element  Description  Record 

(See  subsection  7.8.2) 
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WBS  ELEMENT  DESCRIPTION  RECORD 


WBS  ELEMENT  NO. 


WBS  ELEMENT  TITLE 


ENGINEERING  TASK  DESCRIPTION 
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Instruction  for  the  Preparation  of 
the  WBS  Element  Description  Record 


Block  Entry  Item  Instruction 


1  Original  Date  Enter  the  date  the  original  WBS 

element  was  completed. 

2  Revision  Date  Enter  the  date  each  time  the  WBS 

element  record  is  revised. 

3  Revision  Letter  Enter  a  revision  letter  each  time  the 

WBS  element  record  is  revised,  begin¬ 
ning  with  A  for  the  first  revision, 

B  for  the  second,  etc. 

4  Sheet  _  of  _  Number  of  WBS  element  record  sheets. 

5  WBS  Element  No.  Enter  the  assigned  WBS  element  number 

for  each  task,  i.e.,  1.1,  1.1.2, 

2.3,  etc.  Job  Order  number  may  also 
be  included  here  if  desired. 

6  WBS  Element  Title  Provide  a  short  descriptive  title  for 

WBS  element. 

7  Engineering  Task  Describe  each  task  in  detail  pro- 

Description  viding  a  of  description,  technical 

requirements . 
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Project  Management  Questionnaire 
(See  subsection  7.9) 
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Project  Management  Questionnaire 
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PROJECT  MANAGEMENT  QUESTIONNAIRE 
I.  PROJECT  AUTHORIZATION 


Directive 

Subject 

Questions 

OPNAVINST 

5000. 42B 

Operational 
Requirements 
and  Objectives 

1. 

Has  project  authorization 
been  received? 

FUNDS 

SECNAVINST 
5000. IB 

System 

Acquisition 

1. 

2. 

Has  adequate  funding  been 
received? 

Has  a  financial  plan  been 
prepared? 

SPAWAR 

Acquisition 

1. 

Is  an  AP  required? 

4200. 6D 

Plan  (AP) 

2. 

Is  there  a  valid  AP? 

FAR/DFARS 
Part  7.105 


3.  What  is  AP  identifica 


III.  PROJECT  MANAGEMENT 

SECNAVINST  Organization 


SECNAVINST 

5000.1 

3910.3 

5430.7 

5430.67 

5410.85 


1.  Has  organization  structure 
been  established? 

2.  Have  support  resources  been 
obtained? 


DODDIR 

5100.1 


NAVMATINST 

3910.20 


NOSC  GUIDES 


Staffing 


1.  Is  manpower  level  adequate? 

2.  Is  the  staff  trained  for 
project  requirements? 

3.  Is  there  backup  for  key 
personnel. 


NOSC  GUIDES 


Procedures 


1.  Is  there  a  current  func¬ 
tional  chart? 

2.  Are  the  WBS  elements  defined? 


NAVMATINST 
5000. 21A 
5000. 22A 


Pro j  ect 
Management 


1.  Who  is  handling  "public  infor¬ 
mation"  about  the  system? 


EXHIBIT  L 

(Ref  para  8.0  of  the  Course  Sylubus) 
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NAVMAT 

P-9494 

NAVSO 

P-2457 


DODINST 

7000.2 


MIL-STD-881A 
NOSC  GUIDES 


NAVMATINST 
4855. 1A 

SELNAVINST 

4000.31 


Performance 

Measurement 


2.  Are  relevant  project  recor. 
available? 

3.  Who  is  responsible  for  liaison 
with  the  user? 

4.  Are  user's  requirements  ( 

reviewed  for  possible 
improvement? 

5.  Is  someone  tracking  progress 
of  other  closely  related  sys¬ 
tems  that  could  affect  this 
system? 

1.  If  project  exceeds  $25M  of 
RDT&E  funds  or  $100M  of  cumu¬ 
lative  project  investment,  is 
DODINST  7000.2  followed? 


Program  Review  1.  Does  project  review  provide 

coverage  for  cost,  schedule 
accomplishment,  technical 
performance,  and  logistic 
support? 


Work  Breakdown 
Structure  (WES) 


1.  Has  a  WBS  been  prepared? 

2.  Does  it  include  all  task 
descriptions? 

3.  Have  provisions  been  made  for 
updating? 


Quality 
Assurance  (QA) 


1.  Have  the  elements  of  QA  been  ^ 
considered  for  the  material 
life  cycle,  i.e.,  contract 
definition,  engineering 
development,  production  and 
service  life? 


2.  Has  life  cycle  costing  been 
considered? 


PROJECT  DOCUMENTATION 


NAVMATINST 
5200. 11B 


System 

Description 


1.  Is  there  a  system  description 
written  (non-technical) ? 


Project  Master 
Plan  (PMP) 


1.  Is  a  PMP  required? 

2.  If  PMP  is  NOT  required,  is  an 
alternate  prepared? 

3 .  Has  it  been  approved  ? 

4.  Does  it  cover: 


Historical  data 
Current  requirements/ 
objectives 
Summary  highlights 
System  description 
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MIL-M-38784 

MIL-M-15071G 

OPNAVINST 
4160.2 
SECNAVINST 
5233. IB 


NOSC  GUIDES 


MIL-STD-490 


SECNAVINST 
5233. IB 


Project  management  plan 
Project  milestone  plan 
Definition  plan 
Development,  test,  and 
evaluation  plan 
Production,  installation 
and  base  loading  plan 
ILS  p3  an 

Personnel  and  training  plan 
System  effectiveness  plan 
Reliability/maintainability 
plan? 


Tech  Manuals 

1. 

Are  technical  manuals  (hard¬ 
ware/software)  required? 

2. 

Will  they  be  contracted  or 
done  in-house? 

3. 

Have  outlines  been  prepared 
and  approved? 

4. 

Has  a  valid  verification 
plan  been  prepared? 

5. 

Have  the  manuals  been 
validated/verified? 

Progress 

Reports 

1. 

Do  progress  reports  cover: 

Complete  s  atus 

Potential  problems 
Financial  status 

Milestone  report/status 
Critical  problems? 

Specifications 

1. 

Has  a  system  spec  (Type  A) 
outline  been  developed  and 
approved? 

2. 

Has  the  system  spec  been 
developed? 

3. 

Have  development  specs 
(Type  B)  been  developed? 

4. 

Have  product  specs  (Type  C) 
been  developed? 

Software 

1. 

Have  the  software  specs  been 
developed? 

Performance  spec 
Design  spec 

Subprogram  design  specs 
Common  data  base  design 
documentation 
Program  package 
Operators  manual 
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PROCUREMENT 

FAR 

NOSC  SUPPLY 

FAR/DFARS 

7.105 


FAR 

NOSC  SUPPLY 


SECNAVINST 
7000. 17B 
NAVMATINST 
7000. 17E 


NAVMATINST 
4000. 15A 


ONM  4335.8 


Contract 

Service 


Contractor 


1.  Have  contractual  services 
been  requested  from  Code  21?^ 

2.  Has  complete  procurement 
package  data  been  compiled? 

3.  Has  interface  between  the 
project  and  NOSC  procurement 
been  established? 

4.  Are  contractual  actions  con¬ 
sistent  with  NOSC  procurement 
practices  and  lead  time? 

5.  Is  an  Acquisition  Plan 
required? 


1.  Does  this  project  require 
contractor  assistance? 


2 .  Has  procurement  package  been 
planned,  prepared,  processed 
and  awarded? 

3.  Does  the  contract  include 
sufficient  reporting  require¬ 
ments  to  provide  government 
visibility? 


Contractor  Cost 
Performance 
Measurement  for 
Selected 
Acquisitions 


1.  Will  the  provisions  of  this 
directive  to  Selected  Acqui¬ 
sitions  apply  to  this 
project?  » 


Data 


1.  Are  the  contract  data 
requirements  specified? 


2.  Are  all  specs  clear,  unambig¬ 
uous  and  unrestrictive? 


Performance 


1.  Are  contractor  performance 
evaluations  made? 


SYSTEM  ENGINEERING 


MIL-STD-490 


Specifications 


1.  Are  detailed  specs  prepared 
in-house  prior  to  procurement 
action? 

2.  Are  design  specs  complete 
before  development? 

3.  Does  the  Government  own  all 
manufacturers'  drawings  and 
specs  developed? 

4.  Are  design  specs  accurate  and 
adequate  so  that  competition 
will  be  possible  for  future 
procurements? 
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1 

5.  Have  feasibility  and  effec- 
tiveness  studies  been  com¬ 
pleted  and  evaluated  before 
major  software  or  hardware 
commitments  are  made? 

NAVMATINST 

4120. 97B 

DOD  4120. 3M 

MIL-STD-680 

Standardization 

1.  Has  the  system  been  analyzed 
with  the  intent  of  standardi¬ 
zing  common  parts,  components, 
and  subsystems? 

2.  Will  contract  specifications 
call  for  standardization? 

Review 

1.  Is  a  preliminary  design 
review  schedule? 

2.  Are  critical  design  reviews 
scheduled? 

MIL-STD-499A 

Systems 

Engineering 

Management 

1.  Will  systems  engineering 
management  be  implemented? 

2.  Has  a  System  Engineering 
Management  Plan  (SEMP)  been 
prepared? 

e 

MIL-STD-499A 

Integration/ 

Interface 

1.  Has  the  impact  of  inter¬ 
dependent  tasks  on  ultimate 
project  completion  been 
evaluated? 

2.  Have  existing  systems  been 
studied  for  interface  or 
transition  to  the  new  system? 

3.  Have  detailed  interface 
characteristics  of  all  asso¬ 
ciated  systems  been  described? 

4 .  Has  a  person  been  assigned 
responsibility  for  interface 
control? 

VII. 

DATA  MANAGEMENT 

I 

j 

i 

J 

NAVMATINST 

4000. 15A 

DOD  5010.12 

Data  Management 

1.  Will  project  technical  data 
management  be  in  accordance 
with  the  instructions? 

2.  Has  a  data  manager  been 
appointed? 

3.  Has  a  data  management  plan 
been  prepared? 

4.  Has  a  data  depository  been 
established? 

7-79 
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VIII.  INTEGRATED  LOGISTIC  SUPPORT  (ILS) 


NAVMATINST 
4000. 20B 


Training 


DOD  4100.35 


SECNAVINST 
4000. 20A 


MIL-STD-1369 (EC) 


Validation  and 

Verification 

(V&V) 


Maintenance 


Has  a  spec  tree  been 
established? 


MIL-STD-490 
MIL-M-1507 1G 
MIL-M-38784 
WS-8506 
MIL-E-16400F 


MIL-STD-1369 

MIL-STD-1472 


Specs 

Manuals 

Manuals 

Software 

Electronic 

Equipment 

ILS 


MIL-STD-785 


Human 

Engineering 

Reliability 


Data  change  provisions 
established? 

Have  Forms  DD-1423  been 
prepared 


Has  a  training  plan  and 
schedule  been  prepared? 

Does  the  training  plan  cover 
operators,  maintenance,  per¬ 
sonnel  and  support  personnel? 
Are  schedules  for  personnel 


training  consistent  with  t 
development,  production,  and V 
installation  schedules? 

Does  the  training  plan 
include  requirements  for 
training  devices  and  aids  to 
support  the  training  program? 


Have  V&V  plans  been  prepared? 
Have  site  activation  surveys 
and  reports  been  made? 


Has  a  maintenance  plan  been 
developed? 

Does  the  maintenance  plan 
identify  maintenance  functions 
and  describe  maintenance 
levels  at  which  all  sub¬ 
system  and  components  are  to 
be  processed? 

Will  standardization  goals 
be  established  early  in  the 
project  cycle? 

Is  there  a  system  for 
reporting  malfunctions, 
problems,  etc? 
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Spares 
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Is  there  a  plan  for  develop¬ 
ing  spares  and  repair  parts 
requirements? 


NAVMATINST 
485?. 1A 


MIL-STD-480, 
481,  482  & 
483 


NAVMATINST 
4130. 1A 
OPNAVINST 
4130.1 


Quality 
Assurance  (QA) 


1.  Has  QA  been  considered  for 
both  hardware  and  software? 

2.  Who  is  going  to  perform  QA  on 
tech  data  (manuals,  pro¬ 
cedures,  drawings)? 


Configuration 
Management  (CM) 


Software  (CM) 


1.  Is  CM  required  (hardware/ 
software) ? 

2.  Has  a  CM  plan  been  prepared? 

3.  Have  baselines  beert 
established? 

4.  Have  all  items  beecn  identi¬ 
fied  and  listed? 

5.  Has  a  change  control  board 
(CCB)  been  established? 


n? 


OPNAVINST 

4130.2 

DODDIR 

5010.19(D) 


NAVMATINST  Human  Factors 

3900. 9A 


MIL-STD-1472A 
MIL— H-4 6855 

NAVMATINST  Value 

4858. 8A  Engineering 

(VE) 


FAR,  SECT  1, 
PART  17 


MIL-V-38352 


MIL-STD-100A  Drawings 

MIL-D-1000 

M1L-D-1000/2 

MIL-D-1000/1 

MIL-D-5480 


6.  Are  all  changes  reported  to 
the  CCB? 

7.  Does  the  CCB  secretary  report 
results  of  each  meeting  and 
maintain  records? 

8 .  Do  all  subsystems  have  repre¬ 
sentatives  and  alternates? 

1.  Have  human  engineering  con¬ 
siderations  been  imposed  upon 
concept  formulation,  design 
and  development  of  the  system? 

2.  Has  a  human  engineering  plan 
been  prepared? 

1.  Has  the  program  and  budgetary 
planning  provided  for  VE  con¬ 
siderations  and  effort  during 
the  contract  definition  and 
engineering  development 
phases? 

2.  Has  a  VE  program  requirement 
spec  and  plan  been  prepared 
for  application  in  the  system 
development  contract? 

3.  Do  project  management  plans 
provide  for  the  continuing 
integration  of  VE  considera¬ 
tions  throughout  the  life 
cycle  of  the  systems? 

1.  Will  drawings  be  prepared  in 
accordance  with  MIL-STDS? 

2.  Is  there  a  schedule  for  the 
acquisition  and  development 

of  provisioning  documentation? 
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Support 

Equipment 


IX.  PRODUCT  ASSURANCE 


NAVSEA 

OD  46574B 


3. 


Packaging  and  1 . 
transportation 


NAVMATINST 

Reliability 

1. 

3000.1 

NAVSEAINST 

Reliability  and 

2. 

3900.2 

Maintainability 

NAVELEXINST 

Reliability 

4858.2 

NAVELEXINST 

Maintainability 

3. 

4858.2 

NAVAIRINST 

Reliability  and 

13070.2 

Maintainability 

NAVMATINST 

Quality 

1. 

4855.1 

Assurance  (QA) 

NAVSEAINST 

Quality 

2. 

4855.5 

Assurance  (QA) 

NAVELEXINST 

Quality 

3. 

4855.2 

Assurance  (QA) 

NAVAIRINST 

Quality 

5400.23 

Assurance  (QA) 

Weapons  and 
Combat  Systems 
Product  Assurance 
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Does  the  schedule  for  pro¬ 
curement  and  delivery  of 
parts  conicide  with  system 
delivery? 


Is  there  a  plan  for  the  deve¬ 
lopment  of  support  equipment 
requirements? 

Does  the  schedule  for  pro¬ 
curement  and  delivery  of 
approved  support  equipment 
coincide  with  system  delivery? 


Have  packaging  and  transpor¬ 
tation  requirements  been 
established  for: 


Operational  items 

End  items  to  be  repaired 

Spare  and  repair  parts 


Has  a  reliability/maintain¬ 
ability  program  been 
established? 

Have  the  SYSCOM's  particular 
requirements  been  satisfied? 


Have  the  Center's  require¬ 
ments  been  satisfied? 


Has  a  Quality  Assurance 
program  been  established? 
Have  the  SYSCOM's  particular 
requirements  been  satisfied? 
Have  the  Center's  require¬ 
ments  been  satisfied? 
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NOSC  TD  870 


NOSC  TD  432 


Product 

Assurance 

Requirements 

Product 

Assurance 

Guidelines 


1.  Has  a  product  assurance 
program  been  established? 


MIL-STD-470/785 

882/1472 


NAVMAT  P-949 


TEST  AND  EVALUATION  (T&E) 


ONRINST 

Test  and 

1. 

5210. 2B 

Evaluation 

OPNAVINST 

(Software/ 

3690. 10B 

Hardware) 

2. 

SECNAVINST 

3. 

5233. IB 

NAVMATINST 

4. 

3960. 6A 

NAVMATINST 

5. 

3960. 7A 

6. 

7. 

Has  the  product  assurance 
program  plan  been  completed 
and  approved? 


Have  overall  levels  of 
acceptable  performance  been 
established  by  users? 

Has  a  T&E  Plan  been  developed? 
Does  the  T&E  Plan  agree  with 
development  schedule? 

Does  component  testing  take 
place  prior  to  system  testing? 
Does  the  test  plan  include 
testing  of  interfaces  with 
associated  subsystems? 

Have  training  programs  been 
planned  and  scheduled  for 
test,  evaluation,  installation 
and  maintenance  personnel? 

Does  the  test  plan  clearly 
delineate  the  responsibilities 
and  relationships  of  all 
agencies  (contracting  and 
government)  in  preparing  for 
the  test  and  evaluation  phase? 
Have  test  procedures  been 
prepared? 

Has  liaison  been  established 
with  the  Chief  and  the 
Commander,  Operational  Test 
and  Evaluation  Force 
(COMOPTEVFOR)  early  in  the 
project  cycle? 

At  completion  of  test  and 
evaluation,  will  all  end 
items  be  delivered  con¬ 
currently  with  documentation 
and  evaluation  reports  to 
the  user? 
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XI.  SECURITY 


OPNAVINST 

5510.1G 

DOD  5200. 1R 

OPNAVINST  ADP  Security 

5239.1  A 

NOSCINST 

5500.1  A 


1 .  Has  an  appropriate  Security  Classification 
Plan  or  Guide  been  developed  for  the  system 
components,  and  documents? 

1.  Have  any  appropriate  security  measures 
been  taken  if  you  are  acquiring,  developing, 
using,  or  reconfiguring  ADP  resources? 


XII.  SAFETY 

OPNAVINST 

5100.8F 

MIL-STD-882A 

NAVMATINST 

5100.6A 


System  Safety 
Program  Plan 
(SSPP) 


NOSCINST  Electromagnetic 

5100.8  Environment 

BUMECINST 
6470.1 A 
NAVSEA 
OP3565 
NAVAIR 
6-1-529 
SPAWAR 

0967-LP-624-60 
NOSCINST 
2470. 1C 
OPNAVINST 
2410.1  IB 


1.  Has  a  SSPP  been  prepared  in  accordance 
with  MIL-STD-882A? 

2.  Have  the  SSPP  requirements  been  included 
in  the  funding  schedules,  milestones,  and 
WBS? 

1 .  Does  the  electromagnetic  environment  pro¬ 
vide  for  protection  against  microwave 
hazards? 

2.  Have  Center  frequency  coordination  and 
supporting  procedures  been  followed? 
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(See  subsection  7.11) 
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DISCUSS  MILESTONES  MISSED  (Include  reasons,  effect  on  project,  remedial  action  taken,  and  when / 
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# 


1 

2 

3 

4 


10 


11 


12 


13 


14 


Instruction  for  preparation  and  Completion  of 
Project  Progress  Report 


Block  Entry  Item 


L_ 


From 

To 

NOSC  Project 
Pro j  ect 


Reporting  Period 


Date 


Sub-Pro j  ect 
Task 


Sponsor 


Principal  Investigator 


Associate  Investigator 


Due  this  Reporting 
Period 


Due  Next  Reporting 
Period 


Activities  in  Process 


Instruction 


Enter  originator's  name  and  code. 
Enter  addressee's  name  and  code. 
Enter  the  four  digit  project  number. 


Enter  the  short  title  of  the  program 
or  project.  Identifying  acronym  may 
be  used,  if  applicable. 


Enter  the  ending  date  of  the  period 
covered  in  the  progress  report. 


Enter  the  preparation  date  of  the 
report. 


Enter  the  System  Command's  identi¬ 
fication  number. 


Enter  the  System  Command's  task 
number. 


Enter  the  System  Command  that 
sponsors  the  project. 


Enter  the  name,  code  and  telephone 
number  of  the  person  responsible 
for  directing  the  project  effort. 


Enter  the  name,  code  and  telephone 
number  of  the  primary  person 
responsible  for  the  technical  work. 


Provide  names  and  status  of  acti¬ 
vities  scheduled  to  be  completed 
during  this  reporting  period. 


Provide  names  and  status  of  acti¬ 
vities  scheduled  to  be  completed 
during  the  next  reporting  period. 


Provide  names  and  status  of  acti¬ 
vities  in  process  that  are  related 
to  the  accomplishment  of  milestones. 
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15X7 


Block  Entry  Item 


15 

16 
17 


18 


19 


20 


21 


22 


23 


2A 


Instruction 


Milestone  Status  Number 
Milestone  Identification 
Milestone  Date 


Enter  sequential  number  identified. 
Enter  name  of  milestone. 


Check  One  - 
Made/Missed 


Totals 


Discuss  Milestones 
Missed 


Current  Critical 
Problem 


Anticipated  Critical 
Problem 


Contracts/ 
Purchase  Orders 


Security 

Classification 


Enter  the  milestone  schedule  date. 
If  the  milestone  schedule  date  is 
revised,  enter  the  revised  date. 
Enter  date  that  milestone  is 
comoleted. 


Enter  check  mark  under  appropriate 
colunm  as  to  milestone  made  or 
missed. 


Enter  number  milestones  made  and 
number  milestones  missed  in  appro¬ 
priate  colunm. 


Provide  reasons,  effect  on  program/ 
project,  remedial  action  tf  ken  or 
to  be  taken,  and  when. 


Provide  the  nature  of  critical 
problem,  impact  on  project,  action 
to  be  taken  or  recommended,  and  whet^4^ 


Provide  nature  of  anticipated 
problem  and  remediall  action  planned 
or  taken. 


Provide  contractor's  name,  if  appli¬ 
cable,  item  or  name  of  procurement, 
due  date,  and  status. 


Enter  the  security  classification, 
i.e.,  CONFIDENTIAL,  SECRET,  etc., 
in  the  upper  left-hand  and  lower 
right-hand  corners  of  each  page. 
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SECTION  8 

SYSTEMS  ENGINEERING 


8.1  INTRODUCTION 

8.1.1  References 

MIL-STD-88IA  Work  Breakdown  Structures  for  Defense  Material  Items 
MIL-STD-499A  Systems  Engineering 
NOSC  TD  108  Project  Manager’s  Guide 

NOSC  TD  250  Suggestions  for  Designers  of  Navy  Electronic  Equipment 

8.1.2  Summary 

Systems  engineering  is  both  an  engineering  art  and  a  management  discipline.  This  module  for  project 
managers  is  a  concise  treatment,  which  only  touches  on  the  key  topics  and  issues,  of  a  very  complex 
topic.  Systems  engineering  is  defined  and  then  related  to  project  management.  The  tasks  of  systems 
engineering  and  systems  engineering  management  are  described,  and  commoly  encountered  project 
problems  are  highlighted.  Planning  and  management  tools  of  importance  to  project  managers  are  related 
from  a  systems  engineering  perspective.  Because  of  the  nature  of  systems  engineering,  this  module  tends 
to  tie  together  other  course  topics. 

8.2  DEFINITIONS 

Systems  Engineering:  Systems  engineering  is  the  application  of  scientific  and  engineering  efforts  to 

a.  Transform  an  operational  need  into  a  description  of  system  performance  parameters  and  a 
system  configuration  through  the  use  of  an  iterative  process  of  definition,  synthesis,  analysis, 
design,  test,  and  evaluation. 

b.  Integrate  related  technical  parameters  and  ensure  compatibility  of  all  physical,  functional,  and 
program  interfaces  in  a  manner  that  optimizes  the  total  system  definition  and  design. 

c.  Integrate  reliability,  maintainability,  safety,  survivability,  human,  and  other  such  factors  into 
the  total  engineering  efforts  to  meet  cost,  schedule,  and  technical  performance  objectives 
(MIL-STD-499). 

Chief  Systems  Engineer:  The  individual  tasked  to  supervise  the  systems  engineering  tasks. 
Organizationally,  the  chief  systems  engineer  is  also  a  deputy  project  manager  who  is  responsible  for 
monitoring  and  managing  the  technical  progress  of  the  project. 


8 3  SYSTEMS  ENGINEERING 

Systems  engineering  is  the  “glue”  that  binds  the  project  product  to  the  original  need.  The  original 
requirements  statement  is  provided  in  operational  terms  and  is  usually  too  incomplete  to  support  technical 
design  decisions.  Systems  engineering  tasks  analyze  and  refine  requirements,  translate  operational 


requirements  into  technical  requirements,  and  provide  the  technical  project  monitoring  and  controls 
that  ensure  that  the  product  meets  performance  requirements  within  the  cost  and  schedule  goals  of 
the  project.  Figures  8.1  through  8.5  reflect  some  of  the  issues  of  concern  to  those  involved  in  systems 
engineering. 

Often  the  requirements  statement  is  inadequate  to  support  the  project  effort.  Requirements  may 
be  excessive  to  any  imagined  mission,  attempt  to  violate  physical  laws,  or  be  incompletely  stated.  Any 
of  these  problems  must  be  resolved  before  resources  are  committed  to  the  design. 

Other  problems  are  created  by  the  need  to  “know  everything”  prior  to  beginning  the  project  when, 
in  fact,  the  project  may  be  advancing  the  state-of-the-art.  Systems  engineering  disciplines,  combined 
with  the  information  resources  of  the  Center,  enabie  the  project  team  to  identify  decision  points  and 
apply  appropriate  resources  to  gain  sufficiently  accurate  information  for  those  decisions. 

The  chief  (or  lead)  systems  engineer  is  (normally)  a  deputy  project  manager.  In  this  role,  he/she 
establishes  technical  process,  ensures  communication  within  the  technical  team,  and  oversees  the  internal 
review  processes.  Other  major  management  tasks  include  costing  disciplines  and  risk  management. 

Systems  engineering  includes  extensive  costing  disciplines.  These  range  from  techniques  of  more 
accurately  estimating  and  projecting  project  task  costs  to  techniques  of  establishing  and  tracking  design- 
to-cost  targets  and  life  cycle  cost  targets.  These  disciplines  are  very  important  to  the  successful  employment 
of  the  project  product;  decisions  made  in  the  conceptual  phase,  through  which  only  a  few  percent  of 
the  total  project  cost  is  actually  expended,  often  affect  total  life  cycle  costs  by  as  much  as  two  orders 
of  magnitude.  Systems  engineering  allows  these  cost  factors  to  be  properly  incorporated  in  the  project 
decisions  before  the  actual  dollars  can  be  known. 

Risk  management  is  a  tremendously  important  field,  but  one  which  is  frequently  overlooked.  The 
management  of  technical  risks  is  a  systems  engineering  function,  but  many  of  the  risk  management 
techniques  bear  heavily  on  project  planning.  The  management  of  project  risks  (cost,  schedule,  and 
political  risks)  is  a  project  management  responsibility;  nevertheless,  the  project  manager  may  depend 
heavily  on  the  systems  engineer  for  expertise  in  project  risk  management  as  well.  The  techniques  of 
risk  management  are  now  expressed  in  well-defined  procedures.  Projects  employing  risk  management 
are  not,  of  course,  guaranteed  success,  but  project  managers  who  manage  risks  well  are  significantly 
more  successful  than  those  who  do  not. 

Throughout  the  project  iife,  the  systems  engineering  depends  heavily  on  project  team  experts  in 
design,  product  assurance,  test  and  evaluation,  and  other  project  disciplines  The  most  critical  “original” 
systems  engineering  tasks  occur  during  the  requirements  definition  and  conceptual  phases  where  solid 
engineering  decisions  must  be  made  before  much  of  the  information  used  by  the  other  disciplines  is 
developed.  It  is  during  these  phases  that  operational  requirements  aie  transformed  into  technical 
requirements.  In  the  validation,  design,  production,  and  deployment  phases,  the  systems  engineering 
role  becomes  increasingly  a  design  assurance  role,  coordinating  the  other  technical  tasks.  As  the  project 
product  reaches  deployment,  virtually  all  tasks  are  being  executed  by  the  designated  team  experts,  and 
the  project  manager  often  assumes  the  role  of  the  systems  engineer.  Exceptions  to  this  normal  trend 
include  very  large  projects  and  projects  with  continuing  product  improvement  efforts. 

Systems  engineering  interacts  with  design  to  determine  the  appropriate  levels  of  standardization 
and  design  ownership;  to  ensure  EMX  issues  (these  are  issues  concerned  with  an  integrated  approach 
to  the  study  of  the  total  effect  of  electromagnetics)  are  properly  accounted  for;  and  to  make 
build/buy/modify  decisions.  Systems  engineering  and  product  assurance  cooperated  to  determine  level 
of  repair  and  govemment/industry  design  interfaces.  These  decisions  apply  to  both  hardware  and  software 
design  issues.  Another  important  systems  engineering  design  task  is  the  control  of  hardware/software 
interlaces.  Each  of  these  areas  create  test  and  evaluation  irsues  that  the  test  director  and  the  systems 
engineer  resolve  together. 
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LEVELS  OF  INFORMATION  FOR  DECISION  MAKING. 


0.  Noneducatea  guess 
1 .  Educated  guess  by  a  nonexpert 
l  Educated  guess  by  an  expert 

3.  Expert  advice 

4.  Research  and  analysis 

5.  Analysis  and  simulation 

6.  Diagnosis  of  prior  experience 

7.  Partial  testing  in  use  (such  as  a  Fleet  Research  Investigation  or 
Development  Assist) 

8.  Full-scale  testing  in  use  (such  as  an  Operational  Assisi  or  OPEVAL) 


guesses 


information  developed 
Rom  experience 


>  validated  information 
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LEVEL  OF  INFORMATION 


LEVEL  OF  INFORMATION 


Figure  8.1.  Level  of  information  versus  confidence  and  effort  to  obtain. 


ACQUISITION  PROJECT  SIZE 


PRODUCTIONS 


EGORY 

RDT&E  S 

1 

>50M 

>  200M 

(VERY  LARGE) 

II 

>  20M 

>  50M 

(LARGE) 

III 

>5M 

>  20M  1 

(INTERMEDIATE) 

IV  A 

>  1 M 

>  5M  J 

IV  B 

>  300k 

>  IM  j 

(SMALL) 

IV  C 

>  100k 

>  300k  j 

IV  0 

EVERYTHING 

ELSE 

(VERY  SMALL) 

CRITICAL 


NONCRITICAL 


LOW  PRIORITY  HIGH  PRIORITY 

RANGE  OF  PROJECT  ISSUES 


Figure  8.2.  Project  size  versus  range  of  project  issues. 
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*TD  108.  Program  Manager's  Guide 


Figure  8.3.  Concept  formulation. 
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CONCEPTUAL  APPROACH 


I 


IDENTIFY  INTERNAL  FUNCTIONS  REQUIRED 
TO  TRANSFORM  AVAILABLE  INPUTS  INTO 
DESIRED  OUTPUTS  BEYOND  THOSE  INTEGRAL 
TO  ESTABLISHED  APPROACH 
(INITIAL  SYSTEM  DESIGN) 


LCC 
MODEL 
2nd  CUT 

1 

DETERMINE  SYSTEM  | 

TALENT,  POLICY/DOCTRINE,  FACILITIES, 

TE/TOOLS,  AND  OTHER  RESOURCE 

1 

i 

<? 


DETERMINE 
OF  THE  SYST 
REQUIRING  F 
FUNCTIONAL 

’OPTIONS 

EM 

■ROOF  OF 
FEASIBILITY 

1 

. . ...  .  1 

f 

DETERMIN 
OF  FEASIBI 
DEMONSTR 
ANALYSIS. 
EXPLORAT 
DEVELOPM 

E  METHOD 
LITY 

ATIGN: 

SIMULATION. 

ORY 

ENT 

DETERMINE  AREAS  OF  CRITICAL  | 
RISK  AND  HIGH  RISK  AND 
CRITICAL  PATHS 


TO 

PROGRAM 

PLANNING 


i 

’ 

(SEE  CH  3) 

CHECK  COMPATIBILITY 

OF  RF^fHJRCF  RFOUIRFMFNT5? 

PROGRAM 

WITH  PROGRAM  CONSTRAINTS 

CONSTRAINTS 

REEVALUATE 

RESOURCE 

REQUIREMENTS 


PROVE 

n 

OBTAIN 

|  FEASIBILITY 

WAIVER 

1 

r 

ASSESS 

DEFICIENCIES  & 
REQUIREMENTS 


WRITE  SYSTEM 
SPECIFICATION 
TO  VALIDATION 
PHASE 


m\ 

IN  \ 
ON  J 


Figure  8.4.  Technical  approach  (for  each  possible  concept). 
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SAMPLE  SYSTEM  PAP 
WITH  MAJOR  ISSUES 


SYSTEM 


'  SUBSYSTEM  1 


SET  12  (XI 


SET  13  (X) 


GROUP  201  (0) 


UNIT  1201 


UNIT  1301 


UNIT  2011 


STD  ASSYS 


STD  ASSYS 


ASSY  20111 


ASSY  20112 
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ASSY  21 11 
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SUBSYSTEM  3 


SET  31 


SET  32  (01 


UNIT  3101  (X) 


UNIT  3201 


'31011-31018  . 


-  ASSY  31011 


TO  MODULES 


NOTES: 


(II  THE  LEVEL  OF  DESIGN  OWNERSHIP  DETAILS 
EVERY  DESIGN  CHARACTERISTIC  ABOVE  THE  LEVEL 
AND  FUNCTIONALLY  DESCRIBES  THE  ITEMS  BELOW. 


(21  THE  TWO  COMMERCIAL  UNITS  ARE  PROCURED 
BY  A  CONTRACTOR  AND  INTEGRATED  INTO  AN 
ITEM  WITHIN  THE  CONTRACTOR'S  TASKED 
RESPONSIBILITY.  IF  UNIT  1102  WERE  SUPPLIED  GFE, 
THE  GOVERNMENT  WOULD  ASSUME  INTEGRATION 
RESPONSIBILITIES  FOR  SET  11. 


(31  THIS  PORTION  OF  THE  SYSTEM  INCLUDES  A 
NUMBER  OF  SYSTEM  PECULIAR  FUNCTIONS  WHICH 
REQUIRE  CLOSE  CONFIGURATION  CONTROL. 


(4)  THE  LEVEL  OF  STANDARDIZATION  IS  SET  TO 
CONFORM  TO  THE  LOWEST  OF  LOR  OR  LODO. 
EACH  PARTITION  ABOVE  THIS  LEVEL  IS 
CONTROLLED  BY  A  FUNCTIONAL  SPECIFICATION 
FOR  STANDARDIZATION  PURPOSES. 


GOVERNMENT/INDUSTRY  SYSTEM 
INTEGRATION  BOUNDARY  - 

-  LEVEL  OF  DESIGN  OWNERSHIP  (1 ) 
•  LEVEL  OF  REPAIR 
=  LEVEL  OF  STANDARDIZATION  (4) 


(•)  COMMERCIAL  EQUIPMENT 
(XI  INDUSTRY  DEVELOPED 
'+)  EXISTING  MILITARY  EQUIPMENT 

(01  IN-HOUSE  DEVELOPED 


Figure  8.5.  Sample  system  iiartitionint  with,  major  issues  resolved. 
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8.4  ACTION  ITEMS 

a.  Select  and  invoK  e  a  chief  systems  engineer  in  the  proposal  stage  and  carry  his/her  involvement 
throughout  the  project.  Changes  in  systems  engineer  have  had  a  more  negative  impact  on  the 
project  historically  than  changes  in  the  project  manager.  The  chief  systems  engineer  should 
be  technically  knowledgeable  in  the  key  project  issues,  able  to  communicate  and  work  well 
with  others,  dedicated,  practical,  and  inquisitive. 

b.  Make  use  of  the  extensive  support  assets  in  Codes  16,  17,  91,  92,  93,  95,  and  96.  These  codes 
have  people  experienced  in  the  many  critical  disciplines  associated  with  systems  engineering. 

c.  Make  use  of  NOSC  TD  108.  The  tips  and  information  contained  in  NOSC  TD  108  are  project- 
tested  and  proven  practical. 

d.  Formulate  the  project  work  breakdown  structure  in  accordance  with  MIL-STD-881 ,  but  extend 
the  WBS  to  the  least  significant  configuration  item.  In  order  to  accommodate  the  natural  desire 
to  organize  the  project  functionally  (which  is  more  convenient  in  establishing  work  agreements 
and  intercode  funding),  use  the  last  digit  of  each  work  package  to  encode  the  performing 
organization.  When  using  computer  support,  the  program  can  track  the  project  using  the  WBS 
configuration  or  using  the  project  functional  organization. 


8.5  THE  PATTERN  OF  SUCCESS* 

The  role  of  the  project  manager  is  to  acquire  equipment  which  will  perform  the  required  functions 
at  an  affordable  price  and  by  the  time  they  are  needed.  In  these  days  of  constrained  budgets,  “affordable” 
may  be  defined  as  the  least  total  cost  to  the  government  only  with  the  proviso  that  the  functions  to 
be  performed  are  worth  that  expenditure.  Literally  hundreds  of  studies  have  looked  at  defense  acquisitions 
over  the  past  30  years.  Reading  the  conclusions  and  recommendations  from  a  1949  report  is  like  reading 
the  results  of  a  1974  report.  Project  after  project  fails  to  achieve  its  goals.  Each  report  is  clear;  projects 
fail  to  meet  performance  objectives,  overrun  costs  by  150  percent,  and  slip  schedules  25  to  50  percent. 
In  the  vast  majority  of  cases,  the  project  goals  were  not  achieved  for  the  following  reasons:  misspeci- 
fication  (usually  gross  overspecification  creating  artificial  technical  problems),  failure  to  manage  risks, 
obscuring  of  the  project  goals  through  extraneous  paperwork  requirements,  and  failure  to  define 
adequately  what  is  required.  These  reasons  are,  however,  only  the  symptoms  of  underlying  problems 
in  the  acquisition  community.  The  TELCAM  project  looked  at  successes  and  failures  in  industry  as 
well  as  government;  the  successful  project  has  the  same  traits  whether  in  industry  or  in  government. 
An  acquisition  project  also  shares  many  traits  with  a  small  business,  so  TELCAM  also  solicited 
information  from  the  Small  Business  Administration.  Again,  success  is  a  pattern,  whereas  failure  is 
a  deviation  from  that  pattern.  The  major  difference  between  failures  in  industry  and  failures  in 
government  is  that  a  failing  project  in  industry  is  usually  rapidly  terminated;  the  government  failure 
usually  plods  on  to  an  elegant  wreck. 

What  is  the  elusive  pattern  of  success?  The  projects  cited  as  successes  will  have  two  main  features: 

A  strong,  knowledgeable  project  manager  who  acts  as  the  ultimate  authority  for  all  project 
matters— tasking,  budgeting,  technical  decisions,  etc. 

A  small,  dedicated  team  executing  project  tasks. 


•Excerpted  and  adapted  from  NOSC  TD  108. 
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The  key  words  above  are  strong,  knowledgeable,  ultimate  authority,  small,  dedicated,  and  team. 
Excellent  studies  of  the  nuclear  power  program,1  the  Polaris  system,2  and  NTDS3  are  available  which 
show  these  forces  at  work.  “Strong”  appears  to  be  a  peculiar  necessity  in  the  government  projects, 
as  each  success  seems  to  attain  that  status  in  spite  of  “the  system.”  An  ultimate  goal  of  acquisition 
R&D  must  be  to  change  “the  system”  to  allow  average  individuals  to  be  successful  project  managers. 
Until  that  goal  is  reached,  there  is  still  enough  of  a  task  to  create  knowledgeable  managers.  Some 
spectacular  failures  have  been  managed  by  strong,  unknowledgeable  individuals.  A  project  needs  a 
strong  champion  in  order  to  “steal”  sufficient  authority  to  become  a  purposeful  autonomous  entity, 
but  authority  unwisely  wielded  is  disaster.  The  government  project  manager  is  not  held  accountable 
for  his/her  actions;  accountability  is  the  “quality  assurance”  incentive  used  to  check  authority  in  industry. 

The  first  procurement  of  muskets  by  the  Army  in  1798  seemed  straightforward.  Eli  Whitney 
promised  to  produce  and  deliver  muskets  built  by  assembly-line  techniques,  and  using  interchangeable 
parts,  within  8  months;  actual  delivery  was  made  10  years  late.  Our  military  procurement  problems 
actually  predate  the  nation  itself;  one  verse  of  “Yankee  Doodle”  went 

And  there  we  saw  a  thousand  men 
As  rich  as  Squire  David, 

And  what  they  wasted  every  day 
I  wish  it  could  be  saved 

referring  to  one  of  General  Washington’s  encampments. 

On  March  27, 1794,  Congress  appropriated  $768,000  for  the  construction  and  manning  of  six  frigates. 
Each  frigate  was  to  cost  $100,000.  When  the  UNITED  STATES,  CONSTITUTION,  and  CONSTEL¬ 
LATION  were  finally  launched  in  1797,  each  cost  close  to  $300,000. 

The  innumerable  instances  of  procurement  problems  which  have  occurred  repeatedly  over  the  years 
have  only  worsened  with  time.  The  evolving  acquisition  system  operated  in  ignorance  in  the  1790s, 
and  this  basic  ignorance  exists  today  throughout  the  acquisition  community.  Less  than  30  percent  of 
the  project  managers  interviewed  by  TELCAM  knew  the  operational  objective  of  their  project;  only 
5  percent  could  relate  technical  features  of  the  project  to  operational  considerations.  Only  2  percent 
of  the  project  managers  were  aware  of  any  actions  being  taken  on  their  project  to  reduce  risks  of  any 
kind;  only  half  knew  what  progress  was  being  made  or  what  difficulties  were  being  encountered  on 
major  tasks!  Under  these  circumstances,  it  is  a  wonder  even  greater  failures  do  not  occur  than  those 
already  found.  One  of  the  major  factors  aggravating  this  situation  is  the  lack  of  project  manager 
accountability  for  the  end  item  in  the  field.  A  project  manager  may  only  influence  4  years  of  project 
life,  whereas  the  end  item  may  be  in  use  for  over  20  years.  The  project  manager  determinations  affect 
all  but  a  few  percent  of  the  total  life  cost  of  a  project. 

Figure  8.6  shows  the  percentage  of  total  ownership  costs  committed  during  conceptual  planning, 
design,  development,  acquisition,  and  operations  for  past  major  programs.  In  the  past,  decisions  made 
during  the  concept  and  planning  phases  committed  70  percent  of  the  total  life-cycle  cost  funds  of  a 
program,  while  design,  development,  acquisition,  and  operations  accounted  for  only  30  percent  of  that 
total  cost.  The  effects  of  application  of  life-cycle  cost  analysis  through  the  planning  and  RDT&E  phases 
of  a  program,  and  the  “design  to  cost”  concept  on  new  programs  are  expected  to  change  this  distribution 
considerably  by  affecting  a  larger  portion  of  that  early  70  percent  commitment. 

Notice  that  90.  percent  of  the  total  project  cost  is  fixed  after  only  10  percent  of  the  funds  have 
been  expended.  Unless  the  project  manager  assumes  responsibility  for  the  total,  it  is  impossible  to  attain 

'Nuclear  Navy  (1945-1962),  RG  Hewlett  and  F  Duncan,  Chicago,  1974 

2The  Polaris  System  Development,  Sapolsky,  Harvard,  1972 

^The  NTDS  Development,  RW  Graf,  United  Research,  Inc,  29  Jan  19t4 


the  lowest  possible  project  cost.  Considering  that  support  costs  may  be  altered  by  as  much  as  two  orders 
of  magnitude  by  decisions  in  the  conceptual  phase ,  it  can  be  seen  that  a  naive  approach  to  project 
management  can  have  a  devastating  effect  on  operating  budgets;  likewise,  sound  management  can  lead 
to  a  highly  efficient  use  of  funds. 

The  acquisition  manager  should  try  to  obtain  equipment  which  is  fully  capable  of  doing  the  required 
job  and  which  has  the  following  characteristics: 

Reliable 

Maintainable 

Supportable 

Procurable 

Producible 


8.6  THE  PROJECT  MANAGER 

A  manager  and  a  project  are  established  for  a  single  purpose.  It  makes  no  difference  that  the  project 
is  designated  a  major  program  and  its  manager  a  program  manager,  or  that  the  project  is  called  a 
tasking  with  a  project  engineer  in  charge.  Program  manager,  acquisition  manager,  and  project  manager 
are,  for  the  purposes  of  the  discussion,  synonymous,  being  different  in  scope  but  like  in  character. 
Project  management  is  the  planning,  executing,  directing,  and  controlling  of  a  relatively  short-term 
project  or  systems-oriented  organization  established  for  the  completion  of  specific  goals.  Those  specific 
goals  will  be  the  acquisition  and  implementation  of  military  equipment  and  the  subgoals  associated 
with  each  phase  of  the  cradle-to-grave  life  of  that  equipment;  however,  the  principles  presented  are 
basic,  universal,  and  adaptable  to  many  other  project  circumstances. 

The  project  manager  ideally  will  plan,  organize,  monitor,  and  direct  the  project  to  its  goals  as 
effectively  as  possible.  Efficiency  is  a  secondary  consideration,  since  maximum  efficiency  oflen 
compromises  effectiveness.  It  is  generally  agreed  that,  in  the  competitive  atmosphere  of  military  affairs, 
ineffectiveness  is  catastrophic.  Organizations  which  manage  for  efficiency  are  called  functional 
organizations.  In  executing  their  tasks,  the  project  managers  will  draw  on  expert  assistance  from  many 
functional  areas  and  will  establish  lines  of  organization  control  which  will  allow  them  to  manage 
efficiently.  In  general,  project  managers  have  two  cardinal  rules  to  follow: 

Do  not  do  it  yourself— accomplish  through  the  project  organization. 

Organize  your  resources  to  fit  the  project— be  prompt  and  precise  in  defining  the  organization. 

The  project  organization  exists  within  an  organization  (which  will  normally  be  functionally 
organized).  In  order  to  reach  its  goals,  it  must  live  within  the  chain  of  command  of  its  parent  organization, 
and  it  must  establish  a  chain  of  command  within  itself.  A  chain  of  command  is  an  organization  of 
three  elements:  responsibility,  authority,  and  accountability.  Usually  a  project’s  charter  will  define  the 
project  goals  without  mention  of  these  three  elements.  Organization  instructions  may  define  project 
manager  responsibilities  in  a  general  way  with  only  implications  of  assigning  authority  and  no  actual 
:.""'oun?ability.  In  practice,  the  project  managers  should  assume  that  they  are  fully  responsible  for  meeting 
■1  t  project  goals  and  they  should  assume  all  the  authority  allowed  by  law  and  by  their  supervision 
.■  meet  reponsibilities.  Within  the  project  organization,  project  managers  will  clearly  assign 
responsibilities,  delegate  appropriate  authority,  and  hold  accountable  each  responsible  individual.  The 
key  to  success  will  often  be  the  manager’s  authority  and  ability  to  exercise  and  delegate  it.  Outside 
the  project,  managers  should  elicit  the  cooperation  of  those  who  have  authority  above  them,  to  ensure 
that  they  are  backed  up  by  keeping  their  chain  of  command  informed  truthfully,  concisely,  and 
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Figure  8.6.  Systems  funds  committed  by  initial  planning  decisions. 

specifically.  Authority  is  the  power  to  make  decisions.  It  is  important  to  remember  that  small  decisions 
■must  be  made.  A"no  decision" is  worse  than  a  “wrong decision" because  with  the  wrong  decision  managers 
know  what  they  did  and  can  correct  it;  with  no  decision,  the  situation  will  inevitably  grow  worse,  perhaps 
without  any  indication  of  the  appropriate  corrective  action.  Admiral  Nimitz  was  reputed  to  have  said, 
“the  time  for  taking  all  means  for  a  ship’s  safety  is  while  you  are  still  able  to  do  so.”  Decisions  are 
required  to  solve  problems;  solutions  usually  result  from  perspiration— not  inspiration.  When  managers 
have  a  problem,  they  have  basically  two  methods  available  to  solve  it;  the  important  thing  is  that  the 
decision  be  made. 


PROBLEM  SOLVING 


Scientific  Method 

1 .  Define  the  problem 

2.  State  objectives 

3.  Formulate  a  h>pothesis 

4.  Collect  data 

5.  Classify,  analyze,  and  interpret  data 
against  the  hypothesis 

6.  Draw  conclusions,  generalize,  restate,  or 
develop  new  hypotheses. 

The  solution  should  be  kept  in  perspective  by  asking,  “Is  it  adequate?”  and  “Is  it  too  elaborate?” 

In  order  to  make  decisions,  the  manager  must  be  informed.  The  manager  uses  the  project 
organization  and  procedures  to  keep  informed  of  project  activities,  usually  using  some  form  of  convenient 
management  information  system.  Again,  the  solution  is  tailored  to  the  needs.  On  small  projects,  the 
project  manager  will  keep  directly  informed  about  all  the  specifics  of  the  project.  On  large  projects, 
the  project  manager  will  rely  mainly  on  reports  and  plans  and  will  focus  on  exceptions  to  the  overall  plan. 


Classical  Method 

1.  What  is  the  problem? 

2.  What  are  the  alternatives? 

3.  What  is  the  best  alternative? 
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In  order  to  obtain  up-the-Iine  cooperation  to  get  higher  order  decisions,  the  project  manager  should 
know  the  project  and  also  related  projects.  In  knowing  the  project,  the  manager  can  confidently  relate 
accurate  information  to  his/her  superiors.  This  confidence  and  frankness  can  play  a  role  in  generating 
trust  which  will  be  valuable  if  problems  requiring  outside  assistance  arise.  Also,  the  knowledge  of  other 
projects  will  assist  the  manager  in  recognizing  the  parent  organization’s  perspective  and  in  establishing 
a  priority  to  obtain  the  needed  decision.  Avoiding  “tunnel  mindedness”  can  be  very  helpful  when 
competing  for  a  share  of  limited  organization  resources— especially  funding.  Avoid  “buttering  up” 
reports  to  show  only  good  news;  major  problems  cannot  be  covered  up  and  will  torpedo  this  facade. 
The  project  must  satisfy  the  parent  organization’s  goals. 

The  Project  Manager’s  Guide  (NOSC  TD  108)  is  offered  in  recognition  of  the  fact  that  most  project 
managers  are  good  technical  people  who  may  be  inexperienced  managers.  It  is  also  an  attempt  to  offer 
practical  methods  to  implement  the  recommendations  of  the  various  government  studies  on  reducing 
costs  (see  appendix  B  of  the  guide),  many  of  which  are  not  addressed  by  directives  and  instructions. 
It  is  hoped  that  the  guide  will  serve  as  a  useful  navigational  tool  for  managers  as  they  weave  their 
project’s  course  through  instructions,  budgets,  specifications,  and  the  like  to  a  successful  implementation 
in  the  Fleet. 
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SECTION  9 
CONTRACTING 


9.1  INTRODUCTION 

This  section  provides  a  general  overview  of  the  procuren  nt  process.  Both  Small  Purchase 
procedures  and  Contracts  procedures  will  be  discussed.  These  procedures  are  complex  and  continuously 
changing,  therefore  the  information  provided  here  is  only  intended  to  familiarize  the  program  manager 
with  the  basic  workings  of  the  current  system.  Assistance  on  individual  procurements  should  be  obtained 
by  consulting  with  NOSC  acquisition  personnel. 

9.1.1  References 

NOSC  TD  1038,  Contract  Requirements  Guide  for  Technical  Personnel 

Navy  Supply  Acquisition  Regulation  Supplement  (SUPARS)  (NAVSUP  Publication  560) 

NOSCINST  4200.6B 

NOSCINST  4330.2A 

NOSCINST  4340.1 

NOSCINST  4614. 1C 

DFARS  70.314 

DFARS  25.105 

DFARS  25.7401 

DFARS  25.108 

OPNAVINST  5239.1  A 

NOSCINST  5500.1  A 

SECNAVINST  4210.7 


9.2  ORGANIZATION 

The  procurement  function  is  performed  by  the  Contracts  Division,  Code  21.  The  Contracts  Division 
is  part  of  the  Supply  Department  headed  by  the  Supply  Officer,  Code  20,  and  the  Deputy  Supply  Officer, 
Code  201.  Figure  9-1  shows  the  organization  of  the  Supply  Department. 


9.3  ACQUISITION  CYCLE 

The  phases  that  make  up  the  procurement  cycle  consist  of  planning,  preparation  and  submission 
of  a  requirements  package,  solicitation,  source  selection,  award,  administration,  and  closeout.  NOSC 
Technical  Document  1038,  Contract  Requirements  Guide  for  Technical  Personnel ,  provides  information 
on  acquisition  planning,  requirements  package  (RP)  preparation,  and  source  selection.  Contract 
administration  issues  as  they  relate  to  the  requiring  technical  personnel  are  covered  in  the  Contracting 
Officer’s  Technical  Representative  (COTR)  course.  These  phases  of  the  procurement  cycle  will  therefore 
not  be  covered  here. 


9.4  ACQUISITION  RESPONSIBILITY 

When  an  RP  is  received  in  the  Supply  Department,  it  is  screened  to  ensure  that  the  necessary 
documentation  has  been  provided  and  that  appropriate  approvals  have  been  obtained.  The  supply  system 
is  checked  to  determine  if  the  required  supplies  can  be  obtained  from  stock  and  to  ensure  that  the 
commodity  does  not  require  forwarding  to  an  assigned  agency  for  centralized  buying.  If  the  RP  is 
complete,  and  the  required  supplies  cannot  be  obtained  through  the  stock  system  or  by  an  assigned 
agency,  the  request  is  forwarded  to  the  cognizant  contracts  branch  or  purchase  branch  for  processing. 

Requirements  over  $25,000  that  are  not  covered  by  a  GSA  contract  are  sorted  by  code.  Figure 
9-2  shows  the  Contracts  Division  organizational  chart  with  a  list  of  the  codes  assigned  to  each  contracts 
branch.  Requirements  under  $25,000  and  requirements  covered  by  GSA  contract  (regardless  of  dollar 
value)  are  sent  to  the  Purchase  Branch.  Within  the  Purchase  Branch,  the  requirement  is  assigned  to 
a  Section  based  on  the  commodity  being  acquired.  Table  9-1  provides  a  listing  of  the  commodities 
processed  by  each  Section. 

In  addition  to  *hese  factors,  requirements  where  patent  clauses  are  appropriate  will  be  forwarded 
to  the  contract  branch  cognizant  for  the  requester’s  code  regardless  of  the  dollar  value.  Also,  requirements 
that  will  result  in  an  Indefinite  Quantity  type  contract  will  usually  be  processed  by  the  code’s  cognizant 
contracts  branch  regardless  of  the  dollar  value. 
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figure  9-2.  Contracts  Division  and  assigned  codes. 

9.5  SMALL  PURCHASE  PROCEDURES 

9.5.1  Processing  of  Small  Purchase  Requirements  Packages 

When  an  RP  is  received  in  the  Purchase  Branch,  Code  21 1,  it  is  time-stamped  by  the  receptionist. 
The  receptionist  sorts  the  RPs  into  two  stacks,  one  for  sole  source  requirements  and  one  for  competitive 
requirements.  Each  stack  is  then  sorted  into  groups  by  priority  rating. 

Sorted  RPs  are  given  to  the  cognizant  Section  Head  to 

a.  Screen  RPs  for  deficiencies; 

b.  Review  RPs  to  determine  if  they  are  contained  on  the  “List  of  Items  Requiring  Special 
Attention”  set  forth  in  Appendix  D  to  the  Navy  Suppiy  Acquisition  Regulation  Supplement 
(SUPARS)  (NAVSUP  Publication  560); 

c.  Route  stubs  over  $25,000  to  the  Deputy  for  Small  Business  for  review; 

d.  Route  stubs  over  $5,000  to  the  Deputy  for  Small  Business  when  approval  for  dissolution  of 
a  small  business  set-aside  is  required;  and 

e.  Assign  the  RP  to  a  buyer. 

Upon  receipt  of  the  RP,  the  buyer 

a.  •  Considers  the  priority  rating  to  determine  the  order  in  which  to  process  the  requirement; 

b.  Determines  whether  the  requirement  is  on  GSA  schedule; 

c.  Reviews  the  specification  for  obvious  errors  and  questions  specifications  that  appear  to  restrict 
competition  or  that  contain  ambiguous  o:  contradictory  statements; 
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Table  9-1.  Commodities  processed  by  each  section. 


PURCHASE  BRANCH  -  CODE  211 


SECTION  A  (CODE  2111) 

Cables/Interface  Cables 
Communications  Equipment 
Daisy  Print  Wheels 
Diskettes 

Electrical  Equipment 
Electronic  Equipment 
Lab  Equipment 
Laser  Print  Wheels 
Magnetic  Tape  &  Cartridges 
Marine  Supplies 
Test ' Equipment 
Wire 


SECTION  B  (CODE  21121 


Chemicals 

Clothing 

Copiers 

Furniture 

Gas 

Hardware 

Lumber 

Medical  Equipment/Supplies 
Metals 

Office  Supplies 

(including  ribbons  and  dust  covers  for  Office  Equipment) 
Photographic  Equipment/Supplies 
Safety 
Security 

Subscription  Books 
Typewriters 

Vugraphs/Graphic  Supplies 


SECTION  C  (CODE  2113 ) 

Automatic  Data  Processing  Equipment  (ADPE)/Supplies 

ADPE  Services 

Printers/Plotters 

Software 

Software  Licenses 


Each  section  is  responsible  for  acquiring  repair  services,  maintenance 
services,  and  studies  to  develop  statements  of  work,  applicable  to 
commodities  under  their  cognizance. 
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d.  Determines  the  appropriate  method  of  solicitation,  either  written  Request  for  Quotation  (RFQ) 
or  oral  solicitation; 

e.  Synopsizes  requirements  over  the  thresholds  specified  by  regulation  or  justifies  exempting 
these  requirements; 

f.  Solicits  offerors; 

g.  Sends  quotations  to  technical  personnel  for  evaluation  of  the  technical  acceptability  of  the 
supplies/services,  if  necessary.  (See  Figure  9-3,  the  sample  request  for  technical  evaluation 
and  Figure  9-4,  the  sample  technical  evaluation); 


h.  Requests  additional  funds,  if  required;  and 

i.  Places  the  order. 

9.5.2  Small  Business/Small  Purchase  Set-Asides 


► 


Each  acquisition  of  supplies  or  services  that  has  an  anticipated  dollar  value  of  $25,000  or  less  and 
is  subject  to  small  purchase  procedures  shall  be  reserved  exclusively  for  small  business  concerns  unless 
one  of  the  following  situations  exist: 

a.  The  purchase  must  be  made  from  required  sources  of  supply,  such  as  Federal  Prison  Industries 
and  Industries  for  the  Blind  and  Other  Severely  Handicapped. 

b.  The  contracting  officer  determines  in  writing  that  there  is  no  reasonable  expectation  of  obtaining 
quotations  from  two  or  more  responsible  small  business  concerns  (or  at  least  one,  if  the  purchase 
does  not  exceed  $2,500*)  that  will  be  competitive  in  terms  of  market  price,  quality,  and  delivery. 

c.  The  contracting  officer  does  not  receive  a  quotation  from  a  responsible  small  business  concern 
at  a  reasonable  price  or  the  quotation  does  not  meet  the  required  delivery  date  or  specification. 
In  these  cases,  the  contracting  officer  may  cancel  the  small  business/small  purchase  set-aside 
and  compete  the  purchase  on  an  unrestricted  basis. 

9.5.3  Purchases  Not  Over  $2,500* 

Purchases  not  exceeding  $2,500  may  be  accomplished  without  soliciting  competition  if  the  contracting 
officer  finds  no  reason  to  question  the  reasonableness  of  the  price.  Because  the  administrative  cost 
of  verifying  price  reasonableness  may  more  than  offset  potential  savings  from  detected  instances  of 
overpricing,  the  purchase  price  is  only  verified  when 

a.  The  buyer  or  contracting  officer  suspects  the  price  may  be  unreasonable  based  on  previous 
procurement  history  or  personal  knowledge. 

b.  The  acquisition  is  for  an  item  for  which  no  comparable  pricing  information  is  readily  available 
(e.g.,  an  item  that  is  not  the  same  as,  or  is  not  similar  to,  other  items  that  have  been  recently 
purchased  on  a  competitive  basis). 

The  Federal  Acquisition  Regulation  (FAR)  Part  13  requires  that  purchases  under  $2,500  be 
distributed  equitably  among  qualified  suppliers.  If  practical,  a  quotation  shall  be  solicited  from  other 
than  the  previous  supplier  before  placing  a  repeat  order. 


•The  S2.500  threshold  was  increased  from  SI, 000  by  a  Class  Deviation  to  the  Fedcre’  Acquisition  Regulation  (FAR)  and  Defense 
Federal  Acquisition  Regulation  Supplement  (DFARS).  The  purpose  of  the  deviation  is  to  determine  whether  the  increased 
threshold  will  result  in  overall  cost  savings  to  the  government  by  reducing  the  time  and  resources  needed  to  place  an  order. 
^V*>\  Based  on  information  collected  during  the  deviation  period,  a  determination  will  be  made  to  cither  (1)  return  the  threshold 

l'-'>  to  11,000  or  (2)  revise  the  regulations  to  increase  the  threshold  to  $2,500. 
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21  June  19XX 


From:  A.  C.  Buyer.  Code  2111 
To :  T.  C.  Requester  Code  919 

Subj :  REQUEST  FOR  TECHNICAL  EVALUATION 

Enel:  (1)  Quotations  from  Contractors 
(2)  Sample  Technical  Evaluation 


1.  Enclosure  (1)  is  applicable  to  stub  requisition  number  CA213-88 
and  is  forwarded  to  you  for  technical  evaluation.  Enclosure  (2)  is  a 
sample  technical  evaluation  provided  for  guidance  purposes  only. 

2.  The  following  contractors  have  submitted  quotations: 


a.  S.  J.  Landon  Co. 


b. 

W.  J. 

Miller  Co. 

c. 

P,  A. 

White  Co. 

d. 

Smith  &  Associates 

3.  Please  perform  a  technical  evaluation  of  each  contractor's  offer  to 
determine  if  their  product  meets  all  of  the  requirements  set  forth  in  the 
government's  specifications.  Your  written  evaluation  must  include: 

a.  Identification  of  the  government  specif ication(s)  the  product  does 
not  meet  with  a  statement  that  the  product  is  not  acceptable; 

OR 


b.  A  statement  that  the  contractor  is  offering  a  product  that  meets 
the  specification  in  its  entirety. 

(Note:  In  order  for  a  contractor  to  be  considered  for  an  award,  the 
product  offered  must  meet  or  exceed  the  specification.) 

4.  No  specific  format  is  necessary  for  your  technical  evaluation.  A 
memorandum  is  sufficient. 

5.  For  further  information,  please  contact  the  undersigned  at  X2819 . 


A.  C.  BUYER 


L 

v~v? 

•.‘C’V1 

I 


! 


Figure  9-3.  Sample  request  for  technical  evaluation. 
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9.5.4  Purchases  Over  $2,500  but  Not  Exceeding  $25,000 


9.5.4.1  Competition  Requirements.  The  contracting  officer  shall  solicit  quotations  from  a  reasonable 
number  of  sources  to  promote  competition  to  the  maximum  extent  practicable  and  ensure  that  the 
purchase  is  advantageous  to  the  government,  price  and  other  factors  considered,  including  the 
administrative  cost  of  the  purchase.  Generally,  the  solicitation  of  three  sources  is  considered  adequate 
to  meet  the  requirement  of  promoting  competition  to  the  maximum  extent  practicable.  If  possible  the 
buyer  must  solicit  quotations  from  two  sources  not  included  in  the  previous  solicitation. 


If  only  one  quotation  is  receive  in  response  to  a  competitive  request  for  quotations,  or  the  price 
variance  between  multiple  quotations  reflects  a  lack  of  adequate  competition,  a  statement  shall  be  included 
in  the  purchase  file  giving  the  basis  for  the  determination  that  the  price  is  fair  and  reasonable. 


Solicitations  may  be  limited  to  one  source  if  the  contracting  officer  determines  that  only  one  source 
is  reasonably  available.  This  determination  must  be  supported  by  a  sole-source  justification  from  the 
requester.  NOSCINST  4200.6B  provides  the  required  format  for  a  sole-source  justification  and  instruc¬ 
tions  for  its  completion.  Educational  services  from  a  nonprofit  institution  arc  exempt  from  the  require¬ 
ment  for  a  sole-source  justification. 


9.5.4.2  Determinations  of  Price  Reasonableness  for  Purchase  Orders.  The  pieferred  way  to  determine 
price  reasonableness  in  purchases  over  $2,500  is  by  competitive  quotations.  In  the  case  that  only  one 
quotation  is  received,  or  in  the  case  that  a  lack  of  competition  exists  due  to  wide  variances  in  the  price 
quotations  received,  the  buyer  must  take  further  action  to  determine  the  price  to  be  fair  and  reasonable. 
The  methods  the  buyer  can  use  to  make  this  determination  are  listed  here  in  order  of  preference. 


a. 


b. 


Price  analysis.  The  buyer  must  determine  that  the  item  is  sold  commercially  in  substantial 
quantities  at  a  price  listed  in  a  regularly  maintained  and  published  catalog  or  price  list. 

Value  analysis.  The  buyer  must  establish  all  of  the  following  facts  to  support  a  determination 
of  price  reasonableness: 


1.  The  cost  is  equal  to  the  item’s  usefulness 

2.  All  the  features  of  the  item  are  needed 

3.  There  is  not  an  alternate  item  which  would  be  a  suitable  substitute 

4.  The  item  could  not  be  bought  for  less 


c. 


Independent  government  estimate/technical  analysis.  The  requester  must  pros  idea  reliable 
independent  cost  estimate.  This  estimate  must  be  supported  by  documentation  showing  how 
the  estimate  was  arrived  at  and  should  include  the  amount  and  type  of  labor  and  material 
required  and  the  cost  of  each.  (See  NOSCINST  4330. 2A.)  By  comparing  the  government 
estimate  with  the  contractor’s  quotation,  the  buyer  determines  if  the  price  quoted  is  fair  and 
reasonable. 


d. 


Cost  analysis.  A  cost  breakdown  is  obtained  from  the  contractor.  Each  element  of  the  price 
is  reviewed  by  the  requester  and  the  buyer  to  determine  if  the  price  quoted  is  fair  and  reasonable. 


With  the  exception  of  the  price  analysis  method,  the  requester  plays  a  major  role  in  the  analysis 
of  the  price  quotation  for  items  where  adequate  competition  does  not  exist.  The  requester  must  provide 
the  detailed  supporting  information  necessary  for  the  buyer  to  determine  price  reasonableness. 


9.6  GENERAL  PROCUREMENT  REQUIREMENTS 


This  section  provides  information  on  procurement  requirements  related  to  both  small  purchases 
and  contracts. 
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9.6.1  Stub  Requisition 


A  stub  requisition,  NOSC-SD  4235/4  (REV  11-83),  must  be  included  with  every  request  for 
procurement.  Table  9-2  provides  instructions  for  completing  this  form. 


Table  9-2.  Stub  requisition  instruction.". 


Block 

Legend 

Information  to  be  Inserted 

1 

Code 

Code  submitting  the  requisition 

1 

Stub  Number 

Block  of  numbers  assigned  by  data  processing 

2 

E',' 'mated  Cost 

Total  dollar  value  of  all  items  on  the  requisition 

3 

From:  Requester’s  Name 

Name  of  the  person  requesting  material  or  services 

4 

Extension 

Telephone  extension  of  the  requester 

5 

Other  than  NOSC 

This  block  is  completed  by  tenants  only  (i.e.,  NPRDC, 
NHRC,  and  Public  Works) 

6 

Job  order 

Enter  the  appropriate  job  order  or  RCP  number 

7 

Fund  expiration  date 

Indicate  the  actual  expiration  date  of  the  funds.  If  the  sponsor 
has  imposed  an  administrative  expiration  date,  indicate  this 
date  in  block  29. 

8 

Funded  by  Project  Order 

Indicate  if  the  acquisition  will  be  funded  by  project  orders 

9 

Type  of  Funding 

Indicate  the  type  of  funds  being  cited 

10 

GFE/GFM  authorized 

Indicate  if  government  furnished  equipment/material  will 
be  provided.  11  so,  comply  with  the  requirements  of 
NOSC  INST  4340.1. 

11 

Sole  Source 

Indicate  if  the  acquisition  will  be  Sole  Source.  If  so,  provide 
documentation  1AW  NOSC1NST  4200.6B. 

12 

Accept  Substitute 

Indicate  if  alternate  products  would  be  acceptable 

13 

Date  Material  Required 

Enter  MO/DAY/YR.  (See  Note  (1)  on  page  9-12) 

14 

Priority 

Enter  appropriate  priority  designator  IAW  NOSCINST 
4614.IC 

15-17 

Deliver  to:  Name/ 
Extension/Code 

Enter  the  name,  telephone  extension,  and  code  of  the  per¬ 
son  TO  WHOM  material  must  be  delivered 

18-20 

Location/Bldg. 

Trailer/Room 

Enter  the  exact  location  where  material  is  to  be  delivered 

21-22 

Requester  Signature,  Date 

The  requester  must  sign  and  date  the  stub.  By  doing  so,  the 
requester  certifies  that  the  procurement  conforms  to  the  spon¬ 
sor’s  intended  use  of  the  funds  cited. 

23-24 

Approval  Signature,  Date 

Stubs  must  be  signed  by  authorized  individuals  as  specified 
in  NOSC  INST  4614.1C.  NOTE:  The  same  individual  cited  in 
block  3  or  21  cannot  sign  in  this  block 
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"able  9-2.  Stub  requisition  instruction  (contd). 

25  27  Internal  A  pprova!  Signature  of  the  individual  authorized  to  approve  acquisi¬ 

tions  of  certain  commodities  requiring  internal  approval  (see 
the  list  in  Technical  Document  1038).  The  code  and  date  must 
also  be  provided. 

2$  Appropriation  This  block  must  be  filled  in  by  tenant  activities  only.  The 

headings  in  this  block  are  self-explanatory. 

29  Description  Enter  full  description,  unit  of  issue,  estimated  unit  price, 

quantity,  and  suggested  sources.  If  additional  space  is  re¬ 
quired,  use  NOSC-SD  form  4235/4A,  “Stub  Requisition 
Continuation.” 

30-32  NOT  APPLICABLE  SUPPLY  ACTION 

NOTE  (l).  Date  Material  Required.  Each  requisition  must  specify  a  realistic  delivery  date  based  or  total 
lead  time  to  acquire  the  supplies  or  services.  Lead  time  is  defined  as  the  total  time  elapsed  from  the 
initial  formulation  of  the  requirement  to  actual  receipt  of  the  required  supplies  or  services.  Total  lead 
time  consists  of  the  following 

a.  Requisition  Lead  Time.  The  time  from  the  initial  preparation  of  an  RP  to  the  receipt  of  a 
procurement-ready  RP  by  the  cognizant  contract  branch. 

b.  Procurement  Administrative  Lead  Time  (PALT).  The  number  of  calendar  days  that  elapse 
from  receipt  of  an  RP  in  the  purchasing  component  to  the  effective  award  date  of  the  con¬ 
tract  or  order.  PALT  time  may  be  estimated  using  the  timeframes  set  forth  in  Table  1  of  NOSC 
TD  1038.  If  you  require  assistance,  contact  your  contracting  officer  for  an  estimate  of  PALT 
for  a  particular  procurement. 

c.  Production  Lead  Time.  The  time  from  the  effective  date  of  the  contract  to  the  delivery  date 
specified  in  the  contract.  The  delivery  date  must  be  an  actual  date,  for  example,  25  June,  or 
120  days  after  the  date  of  contract  award,  rather  than  “ASAP”  (as  soon  as  possible).  If  earlier 
deliveries  are  acceptable,  this  should  also  be  noted.  A  required  delivery  date  is  one  of  such 
importance  that  meeting  it  justifies  paying  a  premium.  If  the  required  delivery  date  is  such 
that  upon  its  passing,  the  urgency  for  the  requirement  diminishes  (e.g.,  the  sailing  date  of  a 
ship),  this  should  be  made  clear  in  the  RP.  The  intended  end  use  should  be  identified  with 
an  estimate  of  financial  loss  or  extent  of  failure  to  carry  out  the  mission,  if  this  date  is  not 
met.  This  background  information  or  urgency  may  enable  the  contracting  officer  to  negotiate 
5n  lieu  of  formally  advertising,  regardless  of  the  priority  number  assigned,  and  to  request  ap¬ 
proval  for  the  use  of  o  vertime  premium  costs  in  certain  instances. 

Unreasonable  delivery  dates  at  best  cost  extra  money.  At  worst,  vendors  will  not  bid  on,  or  will 
protest,  a  solicitation  with  unreasonable  delivery  dates.  Both  actions  will  normally  delay  awaid  far 
beyond  wh.it  would  have  originally  been  a  reasonable  delivery  date. 

9.6.2  Synopsis  Requirements 

A  synopsis  is  a  public  notice  of  proposed  contract  actions  and  contract  awards.  The  primary  purpose 
of  the  synopsis  is  to  .mprove  small  b*  mess  access  to  acquisition  information  and  enhance  competition 
by  identifying  contracting  and  subcontracting  opportunities. 

All  proposed  actions  in  the  amount  of  $25, (K'C  and  above  must  ae  synopsized  in  the  Commerce 
Business  Daily  (CBD).  Also,  requirements  of  $10,o00  and  over  must  be  synopsized  if  there  is  not  a 
reasonable  expectation  that  at  least  two  responsive  offers  will  be  received  from  responsible  offeiors. 


Solicitations  cannot  be  issued  until  at  least  15  days  after  the  synopsis  is  published  in  the  CBD. 
In  addition,  synopsized  procurements  must  allow  a  minimum  response  time  of  30  days  from  the  date 
the  solicitation  is  issued.  There  is  one  exception  to  the  30-day  response  time.  ADP  requirements  under 
GSA  schedules  require  only  a  15-day  waiting  period  ufter  publication  in  the  CBD  prior  to  award  of 
the  order  in  accordance  with  DFARS  70.314. 

There  are  some  exceptions  to  the  requirement  for  synopsizing.  The  ones  most  likely  to  apply  to 
NOSC  are  as  follows: 

a.  The  purchase  action  is  classified,  and  the  synopsis  cannot  be  worded  to  eliminate  disclosure 
of  classified  information. 

b.  The  requirement  is  of  such  an  unusual  and  compelling  urgency  that  the  government  would 
be  injured  unless  the  purchasing  office  is  permitted  to  limit  the  number  of  coerces  and  not 
comply  with  the  time  periods  stipulated  by  regulation. 

c.  The  requirement  is  for  foreign  military  sales  requiring  acquisitic  be  made  from  specified 
sources. 

d.  The  requirement  must  be  made  through  another  government  agency  as  required  by  regulation 
or  authorized  by  statute. 

e.  The  purchase  action  is  an  order  placed  under  a  requirements  contract.  Requirements  not  in 
excess  of  $50,000  to  be  purchased  under  nonmandatory  ADP  Federal  Supply  Schedule  (FSS) 
contracts  are  exempt  from  the  synopsis  requirements. 

If  one  of  these  exceptions  applies,  the  requester  should  cite  the  applicable  exception  and  explain 
the  basis  for  its  use.  For  example,  if  unusual  and  compelling  urgency  is  cited,  the  requester  must  describe 
the  circumstances  that  created  the  urgency  and  the  impact  to  the  government  if  the  requirement  is  not 
met  by  a  specified  date. 

9.6.3  Buy  American  Act 

The  Buy  American  Act  requires  that  in  the  acquisition  of  supplies,  only  domestic  end  products 
shall  be  acquired  for  public  use  in  the  United  States.  The  restrictions  of  the  Buy  American  Act  do  not 
apply  to  articles,  materials,  and  supplies 

a.  For  use  outside  the  United  States; 

b.  For  which  the  cost  would  be  unreasonable; 

c.  For  which  the  agen  •  head  determines  that  domestic  pr  ’ference  would  be  inconsistent  with 
the  public  interest; 

d.  That  one  or  more  agencies  have  determined  are  not  mined,  produced,  or  manufactured  in 
the  United  States  in  sufficient  and  reasonably  available  commercial  quantities  of  a  satisfactory 
quality;  or 

e.  Purchased  specifically  for  commissary  -esale. 

Unreasonable  Cost.  DFARS  25.105  provides  procedures  to  evaluate  the  cost  of  foreign  items  to 
determine  if  the  cost  of  domestic  items  are  unreasonable  under  exception  (b). 


Inconsistent  with  the  Public  Interest.  Under  exception  (c),  the  Secretary  of  Defense  has  determined 
that  it  is  inconsistent  with  the  public  interest  to  apply  the  restrictions  of  the  Buy  American  Act  to  the 
acquisition  of  defense  equipment  which  is  mined,  produced,  or  manufactured  in  one  of  the  countries 
specified  in  DFARS  25.7401.  A  list  of  these  countries  is  also  included  in  part  3.4.3  of  TD  1038. 

Nonavailability.  FAR  and  DFARS  25.108  include  lists  of  articles,  materials,  and  supplies  that 
are  subject  to  exception  (d).  Agencies  may  make  additional  determinations  for  unlisted  items  and  shall 
submit  these  item  determinations  to  the  FAR  Council  for  possible  addition  to  the  list. 

The  acquisition  of  foreign  end  products  or  components  on  the  basis  of  nonavailability  shall  be 
made  only  after  a  determination  of  nonavailability  has  been  made  and  the  acquisition  is  approved 

a.  at  a  level  above  the  contracting  officer,  if  the  amount  involved  is  estimated  not  to  exceed  $25,000; 

b.  by  the  chief  of  the  contracting  office  concerned,  if  the  acquisition  is  from  $25,001  to  $250,000; 

c.  by  the  head  of  the  contract  activity  (HCA)  or  his  immediate  deputy,  if  the  acquisition  is  fror> 
$250,001  to  $2  million:  or 

d.  by  the  Secretary  of  the  Navy  or  his  designee  at  ?■.  level  no  lower  than  an  HCA,  if  the  acquisition 
is  estimated  to  exceed  $2  million. 

The  format  for  a  determination  of  nonavailability  is  shown  in  Figure  9-5.  The  approval  levels 
indicated  are  for  acquisitions  of  $25,000  or  less. 

Acquisitions  may  be  made  without  this  determination  if  the  acquisition  is  for  spare  and  replacement 
parts  that  must  be  restricted  to  the  original  manufacturer  or  his/her  supplier.  (In  this  case,  the  acquisition 
must  be  supported  by  a  sole-source  justification  if  it  is  $2,500  or  more  in  value.) 

9.7  MISCELLANEOUS  PROCUREMENT  TOPICS 

9.7.1  Automatic  Data  Processing  (ADP)  Security 

Certain  security  measures  may  be  required  when  you  are  acquiring  ADP  resources.  Guidance  is 
available  from  your  Diviron  ADP  Systems  Security  Officer  (DADPSSO),  the  ADP  Security  Office, 
OPNAVINSY  5239.1  A,  and  NOSCINST  5500.1A. 

9.7.2  Nondevelopment  Items  (NDI) 

In  accordance  with  SECNAV1NST  4210.7,  “Effective  Acquisition  of  Navy  Material,”  the  use  of 
Nondevelopment  Items  (NDI)  will  be  the  principal  means  of  satisfying  the  material  needs  of  the  Navy. 
NDIs  are  defined  as  already  developed  and  available  hardware  and/or  software  that  are  capable  of 
fulfilling  Navy  requirements,  thereby  minimizing  or  eliminating  the  need  for  costly,  time-consuming 
Government-sponsored  research  and  development  (R&D)  programs.  NDI  is  usually  off-the-shelf  or 
commercial-type  products  but  may  also  include  equipment  already  developed  by  or  for  the  Navy,  other 
military  services,  or  foreign  milita.y  forces. 

NDI  solutions  to  stated  requirements  shall  be  aggressively  pursued  by  each  program  manager 
throughout  the  acquisition  process. 

When  an  Acquisition  Plan  (AP)  is  required,  it  must  include  a  description  of  the  extent  to  which 
NDI  is  planned  for  use  in  proposed  acquisitions  and  shall  clearly  justify  those  cases  where  the  use  of 
NDI  is  not  feasible  or  cost  effective. 


NAVAL  OCEAN  SYSTEMS  CENTER 
SAN  DIEGO,  CALIFORNIA  92152-5000 


DETERMINATION  OF  NONAVAILABILITY 


Ref: 


(a)  Procurement  Request  No.  _ 

(b)  Buy  American  Act  (41  U.S.C.  lOa-d) 

(c)  Federal  Acquisition  Regulation  (FAR)  Subpart  25.1 

(d)  Department  of  Defense  FAR  Supplement  (DFARS)  Subpart  25.1 

(e)  Navy  Acquisition  Regulations  Supplement  (NARSUP)  Subpart  25.1 

(f)  Navy  Supply  Acquisition  Regulation  Supplement  (SUPARS)  Subpart 
25.1 


1.  The  requirement  set  forth  in  reference  (a)  is  not  mined,  produced,  or 
manufactured  in  the  United  States  in  sufficient  and  reasonably  available 
commercial  quantities,  of  a  satisfactory  quality.  In  support  of  this 
determination,  the  following  information  is  provided: 

(a)  Identification  of  the  contractor: 


(b)  Description  of  the  item  being  acquired: 


(c)  The  unit  and  quantity: 


(d)  The  unit  price  and  estimated  delivery  cost  of  the  foreign  end  product 


Figure  9-5.  Formal  for  a  determination  of  nonavailability. 


Procurement  Request  No.: 


(e)  The  unit  price  and  estimated  delivery  cost  of  the  unavailable  domestic 
end  product: 


(f)  A  brief  statement  indicating  the  earliest  practicable  date  the 

domestic  end  item  can  be  made  available,  if  not  immediately  available 
to  meet  requirements: 


(g)  A  brief  statement  establishing  the  necessity  for  the  acquisition  and 
indicating  considerations  which  have  been  given  to  the  feasibility  of 
foregoing  the  requirement: 


/ 


(h)  A  statement  establishing  the  nonavailability  of  any  similar  or 
substitute  domestic  end  items ,  indicating  both  the  required 
characteristics  available  only  in  the  foreign  end  item  and  the 
deficiencies  of  the  domestic  items: 


Figure  9-5.  Format  for  a  determination  of  nonavailability  (contd). 
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Procurement  Request  No.: 


(i)  A  statement  describing  the  relationship  of  the  requirement  to  the 
production  of  any  item  on  the  Master  Urgency  Planning  List: 


2.  Based  on  the  foregoing,  the  reference  (a)  requirement  is  determined 
nonavailable  in  accordance  with  references  (b)  and  (c) . 


Requester 

Code 

Date 

Contracting  Officer 

Code 

Date 

Level  Higher 

Code 

Date 

Figure  9-5.  Format  for  a  determination  of  nonavailability  (contd). 
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SECTION  10 

FINANCIAL  MANAGEMENT 


10.1  INTRODUCTION 


10.1.1  References 

NOSCINST  7300.5C  of  6  May  1986,  Letters  of  Intent 

NOSCINST  7300.3B  of  21  June  1984,  Incremental  Programming  on  RDT&E-funded  Contracts 
NOSCINST  7300.2B  of  18  October  1985,  Control  of  Cost  Overruns 
NOSCINST  7300.6A  of  8  May  1986,  Correction  of  Financial  Transactions 
NOSCINST  7321. 1C  of  3  November  1986,  Plant  and  Minor  Property  Control  and 
Accountability 

NOSCINST  7300.7A  of  2  July  1986,  Multiple  Funded  Contracts 

10.2  GOALS  AND  OBJECTIVES 


10.2.1  Budget  Division 

Figure  10.1  introduces  the  Budget  Division,  Code  10,  and  the  following  goals  and  objectives  arc- 
directed  toward  improving  Center  rinancial  management  for  the  benefit  of  both  staff  and  program 
managers. 

a.  Provide  training  and  background  necessary  to  carry  out  financial  management  responsibilities. 

b.  Improve  communications  with  personnel  in  the  financial  arena. 

c.  Improve  Center  financial  planning  and  budgeting. 

d.  Assist  managers/staff  in  the  understanding  and  use  of  Center  financial  reports. 

e.  Explain  the  statutes  and  regulations  that  restrict  what  managers  can  do  financially. 

f.  Improve  Center  financial  management. 

10.2.2  Accounting  Division 

Figure  10.2  introduces  the  Accounting  Division,  Code  12.  Code  12  is  responsible  for 

a.  Control  of  Center  plant  account 

b.  Payroll 
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Budget  Staff  (Analysts) 
—Technical  departments 
—Overhead  codes 
(interface  with  codes) 


LPS  (Laboratory  Program  Summary) 
A-ll  NIF  budget 
Manpower  reporting 
Periodic/special  reports 


Funds  acceptance 
Status  reports 
Billings 
Funding  plans 
Stub  review  and 
processing 


Figure  10.1.  Budget  Division,  Code  10. 


-Flant  account 
-Inventory 
-Travel  costing 
-Labor  cost  transfers 
-Financial  statements 
-Disbursement  processing 


-Obligation 
-Costing/Accurals 
-Bill  paying 
-Reimbursable  oraers 
-Milstrips 


-Travel  claims 
-Issue  of  checks 
-Payroll 

-Labor  processing 


-Development  of  new 
applications 
-Data  conversion  to 
STAFS 
-Problems 


Figure  10.2.  Accounting  Division,  Code  12. 
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c.  Disbursing 

d.  Vendor  payments 

e.  Process  commitments/obligations/costs 

f.  Preparation  of  various  Center  financial  reports 

10.3  THE  NAVY  INDUSTRIAL  FUND  (N1F):  WHAT  IS  IT? 

a.  The  Navy  Industrial  Fund  (NIF)  is  an  accounting  system  based  on  the  1949  National  Security 
Act  (see  Figure  10.3). 

b.  Revolving  fund  concept 

c.  Advantages 

Modern  accounting  methods 

Start  work  before  funds  are  available 

Simple  compared  to  other  government  accounting  systems 

All  costs  originally  charged  to  working  capital 

Cost  data  available  by  job  orders  and  cost  center 

Gives  total  cost  to  project 

10.4  STABILIZED  RATES 

a.  History 

b.  Make  up  of  rate 

c.  How  it  is  applied  and  to  whom 

10.5  OVERHEAD/RATES/SURCHARGES 

10.5.1  Funded  Ra<es  (NOSC  Costs) 

a.  Acceleration  —  Rate  added  to  labor  to  recover  cost  of  fringe  benefits  and  leave. 

b.  General  Overhead  —  Rate  added  to  all  direct  labor  hours  to  pay  for  those  functions  which 
are  general  in  nature,  that  is,  personnel,  supply,  comptroller,  public  works,  etc. 

c.  Productive  —  Costs  within  direct  cost  center  which  cannot  be  related  to  a  project.  Sometimes 
called  indirect  overhead. 

10.5.2  Unfunded  Rates  (Navy  Costs) 

a.  General  —  Statistical  cost  of  militaiy  in  general  cost  center. 

b.  Production  —  Statistical  cost  of  military  in  direct  cost  center,  not  working  on  project. 


10.5.3  Surcharges 


a.  Civilian  retirement 

b.  Interest  on  investment 

c.  Administrative  surcharge 

d.  Packing 

e.  Transportation 

10.6  PROJECT  MANAGEMENT  REQUIREMENTS 

The  following  are  basic  requirements  in  the  financial  management  of  projects: 

a.  Determination  should  be  made,  with  assistance  from  the  budget  analysts,  that  the  funds  provided 
are  appropriate  for  the  w'ork  to  be  performed. 

b.  Work  cannot  start  umil  u.~  customer  order  is  issued. 

c.  Only  authorized  work  and  associated  costs  can  be  charged  to  job  orders  under  a  customer  order. 
All  personnel  should  ensure  that  they  use  the  correct  job  order  when  incurring  costs. 

d.  Prompt  action  should  be  taken  by  the  project  manager  to  obtain  increased  funding  when  it 
is  evident  that  work  cannot  be  completed  within  the  current  authorization. 

e.  Immediate  action  should  be  taken  to  stop  work  on  a  customer  order  when  funds  are  depleted. 

10.7  ACCEPTANCE  OF  FUNDS 

10.7.1  Funds  Required  Prior  to  Start  of  Work 

a.  Work  cannot  be  initiated  nor  costs  incurred  prior  to  receipt  and  acceptance  of  a  valid  sponsor 
order. 

b.  Exceptions:  Commander’s  Orders/Letter  of  Intent.  These  provide  the  only  means  of  starting 
work  in  advance  of  a  regular  sponsor  order. 

c.  Procedures  at  start  of  fiscal  year. 

10.7.1.1  Commander’s  Order.  The  Commander’s  Order  is  characterized  by  the  following: 
a.  It  is  limited  to  an  emergency  situation  such  as 

Loss  or  damage  when  immediate  action  is  necessary  to  prevent  additional  loss  or  damage. 
Problem  in  Fleet  requiring  immediate  attention  to  avoid  loss  of  life  or  damage. 

Events  occasioned  by  unforeseer,  security  situations. 
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b.  The  Center  must  have  documented  communication  from  the  sponsor  that  a  funded  order  will 
be  issued  promptly. 

c.  A  Commander’s  Order  expires  within  30  days  of  issuance. 

d.  A  Commander’s  Order  is  limited  to  $250,000. 

e.  It  cannot  be  used  to  overcome  administrative  lead  time,  which  should  be  considered  in  advance 
planning. 

10.7.1.2  Letter  of  Intent.  The  Letter  of  Intent  is  characterized  by  the  following: 

a.  It  may  be  issued  by  the  sponsor  in  the  interest  of  economical  operations  in  advance  of  a  regular 
order. 

b.  Documentation  Vrom  the  sponsor  is  required. 

c.  Accounting  citation  is  required. 

d.  It  constitutes  an  obligation  on  the  part  of  issuer. 

e.  Amount  of  funding  authorized  should  be  stated. 

f.  It  is  limited  to  30  days  performance  period. 

g.  NOSCINST  7300.5C  of  6  May  1986. 

10.7.2  Types  of  Funding  Documents 

The  Navy  and  other  agencies  use  various  order  forms.  Regardless  of  the  form  used,  these  are  basic 
requirements: 

a.  Work  or  services  must  be  adequately  described. 

b.  The  completion  date  must  be  specified. 

c.  The  Center  must  be  substantially  in  a  position  to  perform  the  work  ordered  expeditiously. 

d.  Government-furnished  material  (GFM)  must  be  identified. 

e.  The  citation  of  funds  must  be  sufficient  to  cover  total  cost  of  the  requested  work. 

f.  Complete  accounting  data  must  be  included  for  billing  purposes. 


There  are  several  types  of  orders: 

a.  Reimbursable  Orders  —  Costs  are  initially  charged  to  the  Center  NIF  account  and  then  billed 
to  the  sponsor  for  reimbursement.  This  is  the  most  common  method  of  funding.  Under  this 
type  of  order  at  least  70  percent  of  the  work  must  be  performed  in-house. 

b.  Direct  Fund  Citations  —  These  are  issued  within  DoD.  They  are  used  when  the  request  involves 
primarily  procurement  or  travel.  The  work  is  not  financed  by  the  Center’s  NIF  account.  The 
accounting  cited  on  the  order  is  used  directly  on  any  contract  or  travel  order  issued  by  the  Center. 
The  issuer  receives  copies  of  contracts  or  travel  orders  issued  and  accounts  for  all  obligations 
and  expenditures. 

c.  Cash  Deposits  —  Required  when  work  is  performed  for  non-DoD  federal  agencies,  private  parties, 
and  state  or  local  governments.  Deposit  required  in  advance  before  work  can  start. 
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10.7.2.1  Reimbursable  Orders.  This  subsection  describes  reimbursable  orders, 

a.  Work  Request  (NAVCOMPT  Form  2275) 

Issued  between  Navy  headquarters  and  field  activities,  and  between  field  activities. 
Required  for  reimbursable  work  funded  by  RDT&E,  Navy  appropriation. 

Used  for  services  of  a  continuing  nature  and  for  purposes  not  applicable  to  a  project  order. 
At  least  70  percent  of  the  work  must  be  performed  in-house. 


Completion  date  cannot  extend  beyond  expiration  date  of  financing  appropriation  or  parent 
order. 


Expiration  dates  for  RDT&E,  Navy-funded  orders  are  subject  to  incremental  funding 
restrictions  (NOSCINST  7300.3B). 


b.  Work  Request  (NAVCOMPT  Form  2276A) 

Can  be  accepted  as  either  a  reimbursable  order  or  a  direct  citation,  or  a  combination  of 
both. 


Can  be  accepted  as  a  project  order. 

c.  Requisition  (DD  Form  1 149) 

Issued  by  Fleet  units  and  ships  to  field  activities. 

At  least  70  percent  of  the  work  must  be  performed  in-house. 

Similar  to  a  work  request  (NAVCOMPT  Form  2275). 

Can  be  accepted  as  a  reimbursable  order  or  on  a  direct  citation  basis. 

d.  Project  Order  (NAVCOMPT  Form  2275) 

Issued  between  Navy  headquarters  and  field  activities  and  between  field  activities. 
Analogous  to  contracts  placed  with  commercial  firms. 

Description  of  work  and  terms  of  order  must  be  specific,  certain,  and  definite. 

Work  must  commence  within  a  reasonable  period  of  time.  Project  order  cannot  be  issued 
if  start  of  work  is  contingent  upon  issuance  of  other  documents  or  other  authorizing  action. 

Must  serve  a  bona  fide  need  existing  in  fiscal  year  in  which  issued. 

At  least  70  percent  of  the  work  must  be  performed  in-house. 


Completion  date  can  extend  beyond  expiration  date  of  financing  appropriation.  All  work, 
including  contract  or  material  deliveries,  must  be  completed  by  date  shown  on  order. 


Cannot  be  issued  for  primary  purpose  of  extending  appropriation. 

Must  be  fully  financed  from  current  obligational  authority. 

Changes  in  scope  or  value  may  be  made  at  any  time  during  period  that  financing 


appropriation  is  available  for  obligation. 

Amendments  after  expiration  of  the  financing  appropriation  can  be  made  for 
Price  increases  (no  change  in  scope) 

No  cost  changes  in  scope  or  completion  date. 
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Project  orders  cannot  be  issued  when  the  primary  purpose  of  the  order  is 
Major  new  construction  of  real  property 

Education,  training,  transportation,  travel,  printing,  communication,  etc. 

e.  DARPA  Order 

Issued  by  DARPA  to  other  agencies. 

At  least  70  percent  of  the  work  must  be  performed  in-house. 

Can  be  accepted  as  a  reimbursable  order  or  on  a  direct  citation  basis. 

Since  funding  is  R&D,  expiration  dates  are  controlled  by  incremental  funding  policy. 

f.  Military  Interdepartmental  Purchase  Request  (MIPR)  (DD  Form  448) 

Issued  between  different  defense  agencies  —  Navy,  Army,  Air  Force,  etc. 

At  least  70  percent  of  the  work  must  be  performed  in-house. 

Can  be  accepted  as  a  project  order  if  it  meets  qualifications. 

Completion  date  requirements  vary  depending  on  appropriation. 

g.  Orders  from  non-DoD  federal  agencies 

Issued  by  other  federal  agencies  such  as  NASA,  DOE,  NOAA,  Interior,  etc. 

Forms  vary  from  agency-unique  purchase  orders  to  memorandum  of  understanding. 
At  least  70  percent  of  the  work  must  be  performed  in-house. 

Completion  dates  vary  depending  on  agency  rules. 

Must  have  cash  advance. 

10.7.2.2  Direct  Cite  Orders.  Documents  that  are  to  be  direct  cited,  such  as  requests  for  contractual 
procurement  (RCPs)  or  “direct  cite”  military  interdepartmental  purchase  requests  (MIPRs),  are  accepted 
through  a  slightly  different  procedure  than  reimbursable  orders: 

An  LPS/DD1498  is  not  required. 

If  the  requested  procurement  is  not  mission  related,  approval  from  SPAWAR  is  required 
before  the  Center  accepts. 

RCPs  are  reviewed  by  the  Supply  Officer,  Code  20,  prior  to  acceptance. 

NOSC  job  orders  are  not  used  when  initiating  contracts.  The  accounting  cited  on  the  RCP 
or  MIPR  is  used  directly  on  the  contract.  A  copy  of  the  RCP  or  MIPR  should  be  attached 
to  each  stub  issued. 

This  subsection  describes  direct  fund  citations. 

a.  Request  for  Contractual  Procurement  (RCP)  (NAVCOMPT  Form  2276) 

Issued  between  Navy  headquarters  and  field  activities  and  between  field  activities. 
Must  relate  to  in-house  NOSC  program;  otherwise  CNM  approval  for  acceptance  is  required. 
Should  be  used  for  specific  contracts. 

Should  not  be  used  for  smaller  material  purchases. 


If  supporting  in-house  services  are  required,  these  should  be  funded  by  a  separate 
reimbursable  order. 

Expiration  dates  vary  with  appropriation. 

b.  Requisition  (DD  Form  1 149) 

Issued  by  Fleet  units  and  ships  to  field  activities. 

Same  rules  as  for  RCP. 

c.  Letter  of  Authorization  for  Travel 

Issued  between  Navy  activities  to  fund  specific  travel  requirements. 

d.  DARPA  Order 

Issued  by  DARPA  to  other  agencies. 

Same  rules  as  for  RCP. 

e.  Military  Interdepartmental  Purchase  Request  (MIPR)  (DD  Form  448) 

Issued  between  different  defense  agencies  —  Navy,  Army,  Air  Force,  etc. 

Same  rules  as  for  RCP. 

10.7.3  Center  Acceptance  Procedures 

All  funding  documents  received  on  Center  are  forwarded  to  Code  103.  After  internal  review  and 
acceptance  by  the  project  manager.  Code  103  accepts  the  document  and  returns  it  to  the  sponsor.  An 
accepted  reimbursable  order  becomes  an  obligation  on  the  sponsor’s  books.  Figure  10.4  presents  the 
fund  acceptance  procedures  for  reimbursable  orders. 

Before  acceptance  of  a  fund  document,  the  budget  analyst  and  the  project  manager  must  review 
it  tc  ensure  plans  are  current  and  that  various  requirements  relating  to  the  document  are  met. 

The  following  questions  are  to  be  considered  when  accepting  a  new  funding  document: 

Is  the  LPS  current  and  approved  by  the  appropriate  Center  official? 

Will  70  percent  of  the  work  on  a  reimbursable  order  be  performed  in-house?  If  not,  an  RCP  or 
other  direct  cite  document  is  required. 

Is  the  funding  sufficient  to  complete  work? 

Is  the  completion  date  adequate? 

For  RDT&E  funded  work,  does  the  completion  date  conform  to  incremental  funding  requirements? 
For  project  orders,  are  special  requirements  met? 

Is  the  type  of  funding  appropriate  for  the  work  being  performed? 

Are  purchases  of  investment  items  planned?  Are  funds  appropriate? 

Are  special  reporting  or  accounting  requirements  specified  in  the  document?  Can  these  be 
accommodated?  by  whom? 
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Figure  10.4.  Fund  acceptance  procedure  for  reimbursable  orders. 


10.7.4  Comparison  of  Appropriations 

Figure  10.5  and  Table  10.1  show  appropriations  from  an  expense/investment  point  of  view,  while 
Table  10.2  presents  the  types  of  funding  appropriations.  Table  10.3  presents  DoD  program  elements 
with  a  detailed  notation  of  the  research  and  development  categories. 

The  following  listings  provide  a  comparison  of  the  different  uses  of  appropriations. 

a.  Research  and  Development 

Basic  and  applied  research 

Studies  —  theoretical,  feasibility,  design,  engineering,  cost  effectiveness 

Experimental  or  prototype  hardware  —  design,  develop,  fabricate,  test 

Software  for  tactical  and  strategic  systems  (requiring  hardware  R&D;  —  design,  develop, 
integrate,  test 

Product  improvement  —  when  expanding  current  performance  envelope 
Development  test  and  evaluation  (DT&E) 

Initial  operational  test  and  evaluation  (IOT&E) 

Investment  items  and  expense  necessary  for  an  R&D  project 
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c. 


Procurement  Appropriations  (APN,  OPN,  SCN,  WPN) 

Investment  hardware  and  software  not  requiring  R&D 

Production  direct  support  —  production  engineering,  quality  assurance,  production  testing, 
equipment  assembly  (excludes  production/procurement  program  management) 

Product  improvement  —  when  item  is  in  production  and  improvement  is  within  current 
performance  envelope 

Test  articles  —  acquisition  of  test  articles  required  for  follow-on  operational  test  and 
evaluation  (FOT&E) 

Operations  and  Maintenance 

Fleet  support 

Maintenance  and  repair  of  operational  items 

Product  improvement  of  items  in  operational  inventory  when  items  are  no  longer  in 
production  and  when  improvement  is  within  current  performance  envelope 

Follow-on  operational  test  and  evaluation  (FOT&E)  (except  for  acquisition  of  test  articles) 

Expense  items  —  labor,  material,  supplies,  travel,  services 

Equipment  costing  less  than  $5,000 


RDT&E  Expense  Investment 

Operators  and  Maintenance  •  • 

Procurement  • 

Aircraft  (APN) 

Weapons  (WPN)  • 

Ships  (SCN)  • 

Other  (OPN)  • 

Other  • 

FMS 

Other  Agencies 
Special  Deposits 


Figure  10.5.  Appropriations. 
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Table  10.1.  Investment/Expense. 


(Specific  definitions  are  contained 

Expense 

Equipment  costing  less  than  $5,000 

Labor  used  for  operations,  maintenance  and 
services 

Spare  assemblies  and  parts  not  centrally  managed 

Nonrepairable  spare  parts 

Consumable  material  and  supplies 

Movable  furnishings,  furniture,  and  galley  equip¬ 
ment  (some  exceptions) 

Services 

Rental  and  leases  (some  exceptions) 

General  motion  picture  procurement  or 
development 

Procurement/production  program  management 

Maintenance  and  repair 

Labor,  material  and  equipment  incorporated 
into  end-item 

Replacement  of  equipment  or  assemblies 
installed  in  major  end-item 

Modification  (alteration,  conversion,  moder¬ 
nization) 

Labor  (except  for  ship  conversion) 

Locally  procured  material 

Minor  construction  (less  than  $200,000  not  funded 
by  MILCON  or  family  housing  appn) 


in  NAVCOMPT  manual  vol.  7) 

Investment 

Equipment  costing  $5,000  or  more  (including 
software) 

Labor  used  in  assembly,  production,  or  construc¬ 
tion  of  investment  item  and  for  direct  support 
costs 

Spare  assemblies  and  parts  centrally  managed 
Modification  kits  and  assemblies 
APA  material 

Facility  construction  and  direct  support  costs, 
design  engineering 

Initial  outfitting  of  major  end  item  of  equipment 

Ammunition  and  explosives 

Procurement/production  direct  support 

Production  testing 
Quality  assurance 
Product  engineering 
Equipment  assembly 
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Table  10.3.  DoD  program  elements  with  a  detailed  notation  of  the  research  and  development  categories. 

DoD  Program  Elements 

0  Support  of  Other  Nations 

1  Strategic  Forces 

2  General  Purpose  Forces 

3  Intelligence  7s  •?  Communications 

4  Airlift  and  Seal. ft 

5  Guaid  and  Reserve  Forces 

6  Research  and  Development 

7  Central  Supply  and  Maintenance 

8  Training,  Medical  and  Other  General  Personnel  Activities 

9  Administration  and  Associated  Activities 

R&D  Categories 

f- .  1  kesearc* . Scientific  study  and  experimentation  directed  toward 

fundamental  knowledge  and  understanding  needed 
for  the  solution  of  identified  military  problems 

6  2  Exploratory  Development . All  effort  directed  toward  the  solution  of  specific 

military  problems,  short  of  major  development 
programs 

6.3  Advance  Development . All  projects  which  have  moved  into  the  development 

of  hardware  for  experimental  or  operational  test 

Those  development  programs  being  engineered  for 
service  use  but  which  have  not  yet  been  approved  for 
procurement  or  operation 

Development,  test,  and  evaluation  not  separately 
provided  for.  Includes  facility  and  military  support 
resources 

6.6  Operational  Systems  Development  . All  ef  fort  having  the  prim  .,-y  objective  of  produci- 

bility  demonstration  and  R&D  phases  of  final  service 
test  of  logistical  and  operational  employment  of  a 
system  approved  for  procurement  and  operational 
deployment 


6.4  Engineering  Development 


6.5  Management  and  Support 


10.7.5  Navy  RDT&E  Incremental  Funding  Policy 


a.  Specific  guidance  is  contained  in  NOSC1NST  7300.3B  of  21  June  1984. 

b.  Goal  —  to  budget  and  finance  RDT&E  work  in  12-month  increments  coincident  with  the  fiscal 


year. 

c.  Effect  on  Center  Funding 


Limits  period  of  time  during  which  the  Center  can  use  funds 
Limits  amount  of  funding  that  can  be  placed  on  contracts 

d.  General  Policy  (see  Figure  10.-S) 

RDT&E  appropriation  is  a  ^-vear  appropriation,  but  it  is  usually  limited  to  12  months 
availability  fo;  labs. 

The  12-month  availability  period  can  be  extended  for  award  of  contracts  for  material  or 
equipment  which  were  ,n!<iated  during  the  first  12-month  increment,  where  award  was 
delayed  because  of  contractual  or  technical  problems. 

Service  contracts  awarded  by  the  Center  with  RDT&E  funds  cannot  extend  beyond  the 
completion  date  on  sponsor  work  request. 

Multiyear  contracts  funded  by  RDT&E  should  be  funded  in  annual  increments  to  coincide 
with  the  fiscal  year. 

Fully  funded  short  term  contracts  (18  months  or  less)  may  be  issued  when  it  is  not  feasible 
to  increment. 

When  budgets  are  prepared  for  RDT&E  funded  projects,  managers  should  take  into  account 
these  incremental  funding  requirements. 


10.8  SPENDING/CONTROL  OF  FUNDS 


10.8.1  NOSC  Project  Numbering  Structure 


The  NOSC  numbering  structure  integrates  a  project  number  with  a  customer  order  and  job  order 
numbers.  This  provides  for  identification  of  different  areas  of  work  at  the  project  number  level,  provides 
funds  control  at  the  customer  order  level,  and  provides  cost  accounting  by  job  order.  Figure  10.7  illustrates 
this  structure. 


Example:  CC54831A01 

Project  No . CC54 

Customer  Order . CC54831A 

Job  Order . CC5483IA01 


10.8.1.1  Project  Number.  The  project  number  (the  first  four  alphanumeric  characters)  identifies 
the  type  of  work  to  be  performed  relative  to  various  Center  mission  areas  and  to  the  specific  project 
effort  within  that  area  of  work.  These  mission  area  indicators  are  listed  in  Table  10.4. 


10.8.1.2  Customer  Order  Number.  The  customer  order  (the  first  eight  alphanumeric  characters)  is 
an  extension  of  the  project  number,  and  it  identifies  the  NOSC  division  managing  the  customer  order, 
the  fiscal  year  of  the  funding,  and  the  specific  sponsor  order  which  is  funding  that  work.  This  is  the 
level  at  which  funds  are  allocated  and  funds  control  maintained.  In  certain  limited  cases,  customer 
orders  may  be  multiple  funded  (see  subsection  10.8.2  for  the  ground  rules). 
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NOSC  Job  Order  Example:  WT01614A01 


Project  Number 
Customer  Order 
NOSC  Job  Order 


(4  characters)  — 

(8  characters)  — 

(10  characters)  — 


WT01 

WT01614A 

WT01614A01 


t 

\ 


i 


Mission 

Specific 

Cognizant 

Fiscal 

Customer  Order 

Job  Order 

Area 

Project 

Division 

Year 

Serial 

Serial 

WT 

01 

61 

4 

A 

01 

Project  Number  —  A  four-character  code  identifying  the  NOSC  project. 


Character  Number 
1 
2 

3  &  4 


Significance 

Alpha  code  for  major  mission  area 
Alpha  code  for  mission  subcategory  area 
Numeric  serial  code  identifying  specific  project 


Customer  Order  Number  —  An  eight-character  alphanumeric  code  identifying  specific  funding  or 
tasks  under  a  project.  It  includes  the  project  number  plus  four  additional  characters. 


Character  Number  Significance 

5  &  6  Two-character  numeric  code  identifying  the  cognizant  division. 

7  Single  numeric  code  identifying  the  fiscal  year  in  which  the  funds  are 
allocated  (e.g.,  1984  =  4). 

8  Single  alpha  code  identifying  the  customer  order  assigned  funding.  Fund 
control  is  exercised  at  this  level. 


NOSC  Job  Order  Number  —  A  10-character  alphanumeric  code  that  identifies  specific  tasks  or 
work  areas  under  a  customer  order  as  needed  for  management  control.  It  includes  the  customer 
order  number  plus  two  additional  characters. 

Character  Number  Significance 

9  &  10  Two-character  numeric/alpha  serial  code  used  for  breakout  of  the  customer 

order  into  job  packages  recording  and  reporting  purposes. 


Figure  10.7.  Explanation  of  the  10-character  NOSC  job  order  number. 
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Table  10.4.  Mission  area  indic2lor  in  the  NOSC  project  numbering  system. 

A.  SYSTEMS  ANALYSIS 

AS  Systems  Analysis 

C.  COMMAND,  CONTROL,  AND  COMMUNICATIONS 

CC,  CD  Command  Control 

CE,  C3  Systems  Human  Engineering 

CF,  C3  Integration  Facility 

CG,  CH  Communications  —  General 

CM,  CN  Communications  —  Naval  Vessels 

CS,  C3  Systems 

CT  Tactical  Sensors  Project  Number 

4  Characters 


E.  ENGINEERING  TECHNOLOGY 

EC  Computer  Sciences 

EE  Electronics  Technology 

EM  Mechani;al  Engineering 

ES  Real-Time  Simulation 

ET  Manufacturing  Technology 

F.  FLEET  SUPPORT 

FA  Fleet-Funded  Programs 

FM  Navy  Fleet  Support 

FN  NSAP  Programs 

H.  HYDROMECHANICS 

HM  Hydromechanics 

M.  MARINE  SCIENCE  AND  TECHNOLOGY 

MA  Environmental  Acoustics 

MB  Airborne  Acoustics 

MB  Deployed  Systems 

ME  Environmental  Quality 

MJ  Radiation  Physics 

MM  Marine  Mammal  Technology 

MP  EM/EO  Propagation 

MR  Arctic  R&D 

MS,  MT  Systems  &  Technology 

N.  EQUIPMENT  &  FACILITIES 

NC  Construction/Installation 

NE  Equipment/Instrumentation 

NI  NICRAD  Program 

P.  PROPOSAL 

PL  Proposals/Planned  Projects 


X  X  XX 

Serial  number  identifying 
' — specific  project. 

Letter  code  identifying  sub- 
— category  of  mission  area. 

Letter  code  identifying  major 
mission  area. 


Sample: 

NEARTIP  —  W701 


ALWT  —  WT02 
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Table  10.4.  Mission  area  indicators  in  the  NOSC  project  numbering  system  (contd). 


S.  SURVEILLANCE  PROGRAMS 


SA 

ss 

ST,  SU,  SV 

sx 

SY 


Aerospace  Surveillance 
Surface  Surveillance 
Undersea  Surveillance 
Ocean  Surveillance 
Surveillance  Systems 


T.  TESTS  AND  SERVICES 


TA 

TC 

TD 

TE 

TG 

TM 

TR 

TT 


ADP/Computer  Services 
Calibration  Services 
SACS/FORACS 
Environmental  Testing 
Graphics 

Machine  Shop  Services 
Range  Testing 
Tenant/Military  Support 


W.  WEAPONS  SYSTEMS 


wc 

WL 

WM 

WS 

WT 

WX 


Fire  Control  Programs 
Launcher  Programs 
Missile  Programs 
Sonar  Programs 
Torpedo  Programs 
Countermeasure  Programs 


X. 


MISCELLANEOUS  SERVICES 
XA,  XB,  XC, 

XD,  etc.  Miscellaneous 


INDEPENDENT  PROGRAMS 

ZD,  ZE  Independent  Exploratory  Development  (IED) 
ZR,  ZS,  ZT  Independent  Research  (IR) 
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10.8.1.3  Job  Order  Number.  The  job  order  is  an  extension  of  the  customer  order  formed  by  adding 
two  digits.  It  is  used  to  identify  specific  segments  of  cost  under  a  customer  order  as  needed  for 
management  purposes.  The  total  10-character  job  order  is  used  on  all  financial  transactions  such  as 
timecards,  travel  orders,  and  stub  requisitions  for  procurement. 

10.8.2  Multiple  Funded  Customer  Orders 

Mixing  of  funds  on  a  customer  order  is  permitted  in  certain  exceptional  cases: 

a.  Work  or  end  product  described  on  each  fund  document  is  the  same. 

b.  Fund  documents  are  of  the  same  type  (i.e.,  all  work  request,  project  orders,  or  other  type). 

c.  Work  described  on  the  fund  documents  is  identical  in  scope  (i.e.,  all  require  identical  portions 
of  various  cost  elements  —  labor,  material,  contracts,  etc.). 

d.  The  work  schedule  starting  and  completion  dates  are  the  same. 

e.  The  fund  documents  contain  identical  terms  —  all  reimbursable  type  orders. 

f.  Fund  documents  are  received  in  same  year.  Carryover  funds  cannot  be  mixed  with  new  funds. 

g.  Funds  are  under  the  same  appropriation  —  all  RDT&E,  all  O&MN,  etc. 

h.  RDT&E  funds  are  within  the  same  R&D  category  (i.e.,  all  6.1,  6.2,  6.3,  etc.). 

Where  a  fund  document  contains  multiple  accounting  line  items  (ACRNs)  for  the  same  project, 
these  ACRNs  must  be  established  as  separate  customer  orders  if  sponsor  task  statements  correlate  to 
the  separate  line  item.  Where  no  correlation  is  possible,  the  funds  can  be  mixed. 

Funding  segments  of  a  multiple  funded  customer  order  will  be  billed  on  a  percentage  basis. 

10.8.3  Overhead/Service  Center  Number  Structure 

A  10-digit  “job  order”  structure  is  used  to  account  for  oveihead  and  service  center  expense.  The 
number  structure  does  not  contain  a  project  number.  Instead,  it  relates  to  the  cost  center  having 
cognizance  of  the  work  and  the  type  of  expense  based  on  prescribed  NIF  expense  elements.  Figure 
10.8  shows  the  NOSC  expense  account  numbering  structure. 


NOSC  Expense  Account  Number  Example:  7140042001 

Type  of  Cognizant  Expense  Element 

Expense  Code  or  Function 

7  1400  420 

(General  (Personnel  Division  (Travel) 

Overhead)  Officer) 


Expense  Account 
Serial 
01 

(1st  Serial) 


Figure  10.8.  The  10-digit  NOSC  expense  account  numbering  structure. 


kwjww  «v  iru  hv  >pj  jtjitj  jtu  *v  awit.vj  ^  r.-ww.wvtv.vjv^' 


# 


10.8.3.1  Type  of  Expense.  A  one-digit  code  identifies  the  type  of  expense  (4  =  service  center, 
6~  indirect  expense,  7  =  general  expense,  8  =  special  center-funded  function,  etc.). 


10.8.3.2  Organizational  Code.  A  four-digit  code  identifies  the  cognizant  organization  at  the  section 
level. 


10.8.3.3  Function.  A  three-digit  code  identifies  the  function  where  such  breakout  is  required  (e.g., 
training,  building  maintenance,  etc.)  or  identifies  the  element  of  expense  (e.g.,  gas,  telephone  service, 
etc.).  Table  10.5  provides  a  representative  listing  of  the  expense  element/function  codes. 


Table  10.5.  The  expense  element/function  code 

structure. 

10 

Severance  Pay 

40 

EEO  Training  &  Support 

11 

Regular  Labor 

41 

Other  Training 

12 

Overtime 

42 

Travel  (except  relocation) 

15 

Downtime 

43 

Printing/Duplication 

16 

Allowed  Time 

45 

Communications 

17 

Awards 

47 

Relocation  Travel 

18 

Military  Duty 

48 

Vehicle  Rental 

19 

Traumatic  Injury 

51 

Electricity 

23 

Material  &  Supplies 

52 

Gas 

24 

Minor  Equipment 

53 

Water 

26 

-Depreciation 

54 

Salt  Water 

27 

Fuels/Lubricants— Ships 

55 

Steam 

28 

Fuels/Lubricants— Other 

57 

Sewage 

30 

Other  Services— Government 

61 

MUR  Buildings 

31 

Other  Services— Commercial 

62 

MUR  Roads  &  Grounds 

32 

Other  Services— PWC  SDiego 

63 

MUR  Equipment 

33 

ADP  Rentals 

65 

MUR  Mechanical  Systems 

34 

Equip.  Rental— non-ADP 

66 

Janitorial 

35 

Transportation  of  Things 

67 

MUR  Service  Craft 

36 

Lease  of  Land/Buildings 

68 

Alterations 

37 

Standard  Level  User  Charges  (SLUC) 

69 

Other  Public  Works  Service; 

38 

Technical  Info  Services 

71 

Bids  &  Proposals 

39 

Computer  Usage 

98 

Transfers  In 

99 

Transfers  Out 
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10.8.3.4  Serial.  A  two-digit  code  that  can  be  used  as  necessary  to  categorize  expenses  for  special 
purposes. 


10.8.4  Commitment/Obligation/Cost/ Accrual 

a.  Use  of  funds  and  expiration  dates 


Spending  Action  Required  by  Expiration  Date 

Work  Request  . Obligate/performance  on  service  contract 

RCP . Obligate/performance  on  service  contract 

Project  Order . Completion  of  work 

b.  Definitions 

Commitment . Reservation  of  funds  for  planned  procurement 

Obligation . Legally  binding  order /contract/task 

Cost . Receipt  of  goods  and  services 

Accrual  . . Estimate  of  value  (goods/services)  received  in 

a  period 


c.  Types  of  transactions 

See  the  types  of  transactions  charted  in  Figure  10.9. 


Labor 

Travel 

Stub  Requisition 

Purchase  Order 

Contract 

Delivery  Order 

Work  Request/MIPR/P.O. 

(when  accepted) 

RCP  —  when  contract  is  awarded 
GBL  (government  bill  of  lading) 
Invoice 


Commitment  Obligation  Cost 

X 

X 

X 

X 

X 

X 

X 

X 

X 


Figure  10.9.  Types  of  transactions. 
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10.8.5  Overruns  (Reference  NOSCINST  7300.2B  of  18  October  1985) 

a.  Prevention  of  overruns 

Review  spending  trend. 

Determine  if  funds  are  sufficient. 

Advise  sponsor  ahead  of  time. 

Obtain  additional  funds. 

Stop  work  —  advise  all  personnel  working  on  project. 

b.  Center  write-off  authority 

NOSC  can  absorb  small  variances  (except  for  Foreign  Military  Sales  [FMS]  and  private  parties) 
as  follows: 

Sponsor  orders  of  $10,000  or  less  —  the  smaller  of  $500  or  10  percent  of  the  order. 
Sponsor  orders  over  $10,000  —  the  smaller  of  $1,000  or  5  percent  of  the  order. 

These  variances  are  written  off  to  Center  operating  results  by  the  Budget  Office,  Code  10. 

c.  Disposition  of  overruns 

Cancel  or  reduce  outstanding  commitments. 

Determine  if  undelivered  material  is  needed  by  another  project.  Initiate  transfer. 
Prepare  letter  to  sponsor  requesting  additional  funds. 

If  the  sponsor  officially  advises  that  funds  are  not  available,  the  overrun  is  charged  to 
Center  operating  results. 

d.  Overrun  reports 

Jeopardy 
Stop  work 
Overrun  notification 
Overruns  outstanding 
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10.9  CORRECTION  OF  FINANCIAL  TRANSACTIONS  (NOSCINST  7300.6A  of  8  May  1986) 


10.9.1  Correction  of  Labor  Charges 

Correction  of  labor  charges  will  be  done  by  either  of  the  following  methods: 

a.  By  sending  to  Code  12  amended  time/labor  distribution  card(s).  The  card(s)  will  show  both 
the  erroneous  and" the  new  job  order  number  and  hours  and  describe  the  error  being  corrected. 
The  erroneous  job  order  number  and  hours  will  be  circled.  Each  week’s  labor  charge  being 
corrected  must  be  on  a  separate  time/labor  distribution  card  and  identify  the  week  being 
collected.  (See  NOSCINST  7300.6A  for  detailed  requirements.) 

b.  By  sending  a  copy  of  the  “Project/Overhead  Status  Report”  (Report  No.  0C1710-7100).  The 
transaction  or  multiple  transactions  in  error  should  be  highlighted  or  underlined.  The  correct 
job  order  to  be  charged  should  be  listed  by  the  transaction  being  corrected.  A  description  of 
the  error  must  be  included  in  the  report  and  be  signed  by  the  appropriate  approving  official. 


10.9.2  Correction  of  Nonlabor  Charges 

Correction  of  nonlabor  charges  will  be  done  by  sending  to  Code  12  a  Change  in  Stub  Requisition 
Cost  Data  (Form  11ND  NOSC  7300/3)  or  a  memorandum. 


10.9.3  Timeframes 

a.  Requests  for  correction  of  labor  charges  received  by  Code  12  WITHIN  2  WEEKS  of  the  date 
reports  containing  the  error  were  distributed  must  (1)  give  an  explanation  of  the  error  and 
(2)  bear  the  approval  signature  of  the  employee’s  supervisor,  the  project  manager,  the  branch 
head  or  the  division  head,  as  appropriate.  Explanations  such  as  “out  of  funds,”  “clerical  error,” 
“on  travel,”  etc.,  are  unacceptable  reasons  for  correction.  Describe  the  error.  Such  requests 
will  be  processed  upon  approval  of  the  Head,  Accounting  Division,  Code  12. 

b.  All  other  transfer  requests  received  by  Code  12  (including  labor  corrections  over  2  weeks  old) 
must  (1)  give  a  thorough  justification  and  (2)  bear  the  approval  signature  of  the  appropriate 
division  head.  Such  requests  will  be  processed  by  Code  12  only  upon  the  written  approval  of 
the  Comptroller,  Code  0901. 
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10.10  PLANT  AND  MINOR  PROPERTY  CONTROL  &  ACCOUNTABILITY  (NOSCINST 
7321.1C  of  3  Nov  1986) 


10.10.1  Definitions 

a.  Plant  Property.  Plant  property  is  all  Navy-owned  real  property  and  personal  property  of  a 
capital  nature  (i.e.,  with  a  unit  cost  of  $5,000  or  more  and  a  useful  life  of  more  than  2  years). 
There  are  four  classes  of  property  for  purposes  of  management  and  financial  control.  The 
four  classes  are  divided  into  two  groups:  real  property  and  personal  property. 

b.  Real  Property 

1.  Class  1  —  Land. 

2.  Class  2  —  Buildings,  improvements,  and  utility  systems.  Included  in  this  category  are  the 
costs  of  equipment  and  the  installation  of  equipment  that  becomes  an  integral  part  of  a 
building,  improvement,  or  utility  system. 

c.  Personal  Property 

1 .  Class  3  —  Equipment  having  an  estimated  or  actual  cost  to  place  in  use  of  $5,000  or  more 
per  item,  a  useful  life  of  2  years  or  more,  and  not  classified  as  “industrial  plant  equipment.” 

2.  Class  4  —  Industrial  plant  equipment  having  an  estimated  or  actual  cost  to  place  in  use 
of  $5,000  or  more  per  item. 

d.  Minor  Property.  Minor  property  is  property  having  a  unit  cost  of  $300  to  $4,999,  plus  all 
audiovisual  equipment  regardless  of  cost. 

10.10.2  Acquisition 
Equipment  may  be  financed  by 

a.  Sponsor.  Plant  and  minor  property  purchased  with  sponsor  funds  must  also  be  tagged  with 
property  decais  and  includes  equipment  procured  for  technical  evaluation  under  special  task 
assignments,  equipment  unique  to  a  single  project,  and  equipment  designed  and  developed 
for  a  single  project.  Sponsor-purchased  items  must  be  disposed  of  in  accordance  with  the 
sponsor’s  instructions. 

b.  Asset  Capitalization  Program  (ACP).  Plant  property  items  with  a  value  of  $5,000  or  greater 
and  a  useful  life  of  2  years  or  more  are  procured  under  the  ACP.  These  items  are  picked  up 
in  the  plant  property  system  and  later  depreciated  to  a  Center  job  order  number.  These  items 
will  be  completely  depreciated  before  disposal. 

c.  NIF  Funded.  Minor  property  is  financed  with  Center  overhead  funds.  These  purchases  are 
charged  to  the  job  order  upon  receipt  of  the  equipment. 

d.  Transfers.  Equipment  items  are  acquired  through  transfer  from 

1.  Other  Activities.  Equipment  is  transferred  from  other  activities  to  the  Center.  Transfer 
of  accountability  is  done  by  an  official  letter  from  the  transferring  activity  enclosing  the 
original  DD  Form  1342. 


2.  Sponsors.  Sponsors  may  furnish  plant  and  minor  property  to  the  Center  at  no  cost  by 

(a)  Authorizing  issues  from  the  Appropriation  Purchases  Account  (APA). 

(b)  Diverting  purchases  to  the  Center  under  contracts  controlled  by  the  sponsor. 
Authority  for  the  transfer  of  these  items  to  the  Center  without  cost  must  be  included 
on  the  sponsor’s  order  (e.g..  Project  Order  or  Work  Request)  or  an  amendment 
thereto.  Unless  otherwise  specified,  these  items  will  be  picked  up  in  plant  and 
minor  property  as  “New  Contributed  Equipment”  and  disposed  of  later  when 
the  item  is  no  longer  of  any  use  to  the  Center. 

3.  Donated  Property.  The  Commander,  NOSC,  may,  under  special  circumstances,  accept 
personal  property  as  a  gift  from  a  private  party.  Such  items  must  be  tagged  and  accounted 
for  in  the  same  manner  as  “New  Contributed  Equipment”  and  disposed  of  by  the  Center 
when  the  item  is  no  longer  of  use. 


10.10.3  Depreciation 

a.  Depreciation  records  a  decrease  in  the  value  of  assets  due  to  wear  and  tear  or  decay. 

b.  Depm  iation  is  recorded  on  all  assets  monthly.  Sponsor  owned  and  new  contributed  assets 
are  stp;  istically  depreciated.  Assets  purchased  through  ACP  and  old  contributed  items  must 
be  depreciated  as  an  actual  expense.  Only  ACP  assets  require  full  depreciation  over  the  life 
of  the  asset  or  upon  its  disposition.  Depreciation  can  be  charged  to  any  job  order. 


•0.11  MULTIPLE  FUNDED  CONTRACT’S  (NOSCIN3T  7300.7A  of  2  July  1986) 


10.11.1  Policy 

a.  Multiple  funding  is  to  be  avoided  when  possible. 

b.  Multiple  funded  delivery  /task  orders  should  be  infrequent.  A  purpose  of  a  delivery  order  contract 
is  to  provide  a  means  to  order  specific  work  definable  to  a  single  source  of  funding.  Costs 
on  a  multiple  funded  delivery/task  must  be  traceable  to  the  correct  fund  source. 

c.  Multiple  funding  must  be  approved  by  the  Comptroller,  Code  0901,  before  recording  an 
obligation. 

d.  In  no  instance  will  approved  multiple  funding  specify  the  recording  of  expenditures  on  customer 
orders  on  a  “first-in,  first-out”  basis. 

e.  Costing  to  the  customer  orders  identified  on  a  multiple  funded  contract,  task,  or  delivery  order 
will  be  based  upon  rationale  approved  by  Code  0901  (e.g.,  number  of  units  procured,  the 
proportion  of  funds  each  customer  order  provides  to  the  total  funding)  before  award. 

10.11.2  Responsibilities 

a.  NOSC  program  managers  are  responsible  for  completing  a  NOSC  Procurement  Funding  Plan 
(Form  NOSC-SD  7300/20)  for  all  stubs  that  will  result  in  a  completion  (“C”  type)  and/or 
delivery  order  (“D”  type)  contract. 
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b.  The  Comptroller,  Code  0901 ,  and  the  Contracts  Division,  Code  21 ,  are  responsible  for  approving 
the  procurement  funding  plan  when  multiple  funding  is  indicated. 

10.11.3  Contract  Characteristics 

a.  Severable—  a  contract  or  task  that  can  logically  and  reasonably  be  broken  in  smaller  increments. 
The  test  of  whether  a  contract  or  task  is  severable  or  not  is  whether  a  smaller  portion  of  the 
effort  can  be  defined  and/or  described  such  that  inspection  for  the  purpose  of  determining 
compliance  can  reasonably  be  made  and  thereby  a  basis  for  acceptance  or  rejection  of  the 
service  or  supply  exists.  A  contract  that  calls  for  a  contractor’s  time  and  effort  rather  than 
a  concrete  end  product  would  be  considered  a  severable  effort.  The  contract  objective  is  for 
the  Government  to  receive  value  as  work  is  being  done.  A  severable  contract  may  not  extend 
beyond  the  work  request  expiration  or  year  of  the  appropriation,  whichever  is  sooner. 

b.  Nonseverable  —  a  contract  or  task  that  is  the  smallest  inspectable  unit  of  work.  A  task  is 
nonseverable  when  it  cannot  be  further  subdivided  and  when  each  subdivision  can  be  evaluated 
for  contractor  compliance  with  the  Statement  of  Work.  The  contract  objective  is  for  the 
Government  to  receive  value  when  the  work  is  complete.  Nonseverable  contracts  may  extend 
beyond  the  expiration  date  of  the  funding  order  and/or  the  year  of  the  appropriation.  However, 
a  “bona  fide  need”  requirement  stipulates  that  a  delivery  cannot  be  set  so  far  into  the  future 
so  as  to  imply  that  there  was  not  a  bona  fide  need  in  the  fiscal  year  ordered. 
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SECTION  11 
HUMAN  FACTORS 


11.1  INTRODUCTION 


11.1.1  References 

MIL-STD-1472  C,  Human  Engineering  Design  Criteria  for  Military  Systems,  Equipment  and 
Facilities,  2  May  1981 

MIL-H-46855B,  Human  Engineering  Requirements  for  Military  Systems,  Equipment  and 
Facilities,  21  January  1979 

Human  Factors  Design  Handbook,  Wesley  E.  Woodson,  McGraw-Hill  Book  Company,  1982 
Air  Force  Logistics  Command,  Human  Factors  Engineering  Computer  Based  Instructional 
Course 

NOSC  TD  250,  Revision  A,  Suggestions  for  Designers  of  Navy  Electronic  Equipment,  May  1985 

11.1.2  Summary 

See  text.  Also  consider  the  words  of  Albert  Einstein,  “Concern  for  man  himself  and  his  fate  must 
always  form  the  chief  interest  of  all  technological  endeavors.” 


11.2  GENERAL 


Human  Factors,  Human  Engineering,  Human  Factors  Engineering,  Man-Machine  Interface, 
Human-Computer  Interface,  User-Computer  Interface,  Man-Machine  Technology,  Ergonomics.  These 
are  all  terms  that  are  used,  sometimes  interchangeably,  to  indicate  those  investigators  who  treat  the 
human  user  as  part  of  the  system  design  process.  Human  factors  engineering,  or  HFE,  is  the  practice 
of  designing  products  so  that  a  human  being  can  use  these  products  for  their  designed  purposes,  operate 
them  easily,  service  them,  and  support  them  in  situ.  All  of  this  should  be  accomplished  with  a  minimum 
of  stress  and  a  maximum  of  efficiency.  In  simple  terms,  human  factors  are  characteristics  of  people 
—  characteristics  such  as  size,  shape,  ability  to  see  and  ’  ear,  strength,  intelligence,  temperament, 
forgetfulness,  and  weakness.  Such  characteristics  —  the  human  factors  —  must  be  taken  into  account 
so  that  human  beings  and  things  made  for  their  use  will  go  well  together. 


11.2.1  Purpose 

The  purpose  of  this  section  is  to  provide  NOSC  program  managers  with  an  understanding  of  the 
need  for  and  benefits  of  including  human  factors  expertise  as  part  of  the  program  design  team  and 
to  provide  some  useful  references  to  consult  for  answers  to  human  factors  questions. 


I 


11.2.2  Background 


A  report  by  the  Navy  Research  Advisory  Committee  on  Man-Machine  Technology  in  the  Navy, 
December  1980,  stated 

The  human  element  has  become  the  most  critical,  most  problematic  and  most  costly  component 
of  the  Navy.  Meanwhile,  increasingly  complex  hardware  systems  are  being  developed  and  procured 
for  Fleet  use. 

Given  present  trends,  the  Navy  will  find  itself  unable  to  operate  and  maintain  its  systems,  in  either 
the  short  or  long  term,  with  the  numbers  of  skilled  personnel  necessary  for  effective  mission 
accomplishment. 

A  Report  to  the  Congress  of  the  United  States  by  the  Comptroller  General  in  January,  1981, 
“Effectiveness  of  U.S.  Forces  Can  Be  Increased  Through  Improved  Weapon  System  Design”  concluded 

There  are  indications  that  human  ineptitude  or  poor  human  reliability  may  cause  over  50  percent 
of  all  weapon  system  failures.  The  increasingly  complicated  nature  of  modern  military  systems 
together  with  internal  military  personnel  problems  suggests  that  human-induced  errors  both  in 
operations  and  maintenance  could  also  increase  unless  more  attention  is  paid  to  this  problem  during 
design  and  development.  Weapon  systems  designs  have  been  dictating  manpower  requirements. 
What  is  needed  is  a  continuing  interface  between  the  system  designers  and  the  manpower  planners 
with  manpower  requirements  influencing  system  design  and  vice  versa. 

If  the  design  of  systems  is  to  adequately  consider  all  the  human  limitations  (including  skill  levels, 
proficiency,  availability,  environmental  stress,  and  fatigue),  military  specifications,  standards,  and 
handbooks  must  address  these  factors.  Existing  documents  do  not.  Also,  common  methodologies 
and  sources  of  data  are  needed  to  forecast  skill  levels  of  potential  military  personnel  5  to  10  years 
in  the  future.  This  information,  which  would  be  extremely  valuable  to  system  designers  and  testers, 
is  currently  not  available. 

Finally,  there  does  not  appear  to  be  sufficient  emphasis  on  testing  systems  from  a  human  reliability 
standpoint  particularly  in  the  developmental  stages  of  the  acquisition  process.  This  could  result 
in  design  errors  requiring  expensive  modifications  after  the  system  is  deployed. 

An  Army  technical  memorandum  indicated  the  importance  of  the  operator’s  and  maintainer’s 
relationship  to  an  item  of  hardware. 

People  are  the  only  responsible  agents  in  the  system.  No  matter  how  small  the  roles  assigned  to 
people,  they  are  responsible  roles.  People  determine  whether  the  system  is  ready  to  operate,  what 
it  is  to  do,  how  and  when  it  is  to  do  it,  when  and  what  variations  in  performance  are  to  occur, 
and  what  constitutes  adequate  or  complete  performance.  People  decide,  control,  guide  change, 
and  evaluate.  They  are  expected  to  anticipate,  detect,  compensate  for,  and  explain  any  undesirable 
variations  in  performance.  And  their  errors  assume  a  significance  commensurate  with  their 
responsibilities. 

These  relatively  recent  reports  point  out  the  importance  of  the  human  being  as  a  system  component 
and  reiterate  problems  that  have  existed  as  long  as  human  beings  have  been  required  to  use  tools  to 
perform  work.  The  need  for  human  factors  as  a  discipline  escalated  during  World  War  II  when  the 
armed  forces  recruited  thousands  of  men  from  all  walks  of  life  and  faced  the  problems  of  training 
them  to  perform  unfamiliar  tasks  quickly  with  military  hardware. 
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always  form  the  chief  interest  of  all  technological  endeavors.’’ 


11.2  GENERAL 


Human  Factors,  Human  Engineering,  Human  Factors  Engineering,  Man-Machine  Interface, 
Human-Computer  Interface,  User-Computer  Interface,  Man-Machine  Technology,  Ergonomics.  These 
are  all  terms  that  are  used,  sometimes  interchangeably,  to  indicate  those  investigators  who  treat  the 
human  user  as  part  of  the  system  design  process.  Human  factors  engineering,  or  HFE,  is  the  practice 
of  designing  products  so  that  a  human  being  can  use  these  products  for  their  designed  purposes,  operate 
them  easily,  service  them,  and  support  them  in  situ.  All  of  this  should  be  accomplished  with  a  minimum 
of  stress  and  a  maximum  of  efficiency.  In  simple  terms,  human  factors  are  characteristics  of  people 
—  characteristics  such  as  size,  shape,  ability  to  see  and  hear,  strength,  intelligence,  temperament, 
forgetfulness,  and  weakness.  Such  characteristics  —  the  human  factors  —  must  be  taken  into  account 
so  that  human  beings  and  things  made  for  their  use  will  go  well  together. 


11.2.1  Purpose 

The  purpose  of  this  section  is  to  provide  NOSC  program  managers  with  an  understanding  of  the 
need  for  and  benefits  of  including  human  factors  expertise  as  part  of  the  program  design  team  and 
to  provide  some  useful  references  to  consult  for  answers  to  human  factors  questions. 
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11.2.2  Background 

A  report  by  the  Navy  Research  Advisory  Committee  on  Man-Machine  Technology  in  the  Navy, 
December  1980,  stated 

The  human  element  has  become  the  most  critical,  most  problematic  and  most  costly  component 
of  the  Navy.  Meanwhile,  increasingly  complex  hardware  systems  are  being  developed  and  procured 
for  Fleet  use. 

Given  present  trends,  the  Navy  will  find  itself  unable  to  operate  and  maintain  its  systems,  in  either 
the  short  or  long  term,  with  the  numbers  of  skilled  personnel  necessary  for  effective  mission 
accomplishment. 

A  Report  to  the  Congress  of  the  United  States  by  the  Comptroller  General  in  January,  1981, 
“Effectiveness  of  U.S.  Forces  Can  Be  Increased  Through  Improved  Weapon  System  Design”  concluded 

There  are  indications  that  human  ineptitude  or  poor  human  reliability  may  cause  over  50  percent 
of  all  weapon  system  failures.  The  increasingly  complicated  nature  of  modern  military  systems 
together  with  internal  military  personnel  problems  suggests  that  human-induced  errors  both  in 
operations  and  maintenance  could  also  increase  unless  more  attention  is  paid  to  this  problem  during 
design  and  development.  Weapon  systems  designs  have  been  dictating  manpower  requirements. 
What  is  needed  is  a  continuing  interface  between  the  system  designers  and  the  manpower  planners 
with  manpower  requirements  influencing  system  design  and  vice  versa. 

If  the  design  of  systems  is  to  adequately  consider  all  the  human  limitations  (including  skill  levels, 
proficiency,  availability,  environmental  stress,  and  fatigue),  military  specifications,  standards,  and 
handbooks  must  address  these  factors.  Existing  documents  do  not.  Also,  common  methodologies 
and  sources  of  data  are  needed  to  forecast  skill  levels  of  potential  military  personnel  5  to  10  years 
in  the  future.  This  information,  which  would  be  extremely  valuable  to  system  designers  and  tes*ers, 
is  currently  not  available. 

Finally,  there  does  not  appear  to  be  sufficient  emphasis  on  testing  systems  from  a  human  reliability- 
standpoint  particularly  in  the  developmental  stages  of  the  acquisition  process.  This  could  result 
in  design  errors  requiring  expensive  modifications  after  the  system  is  deployed. 

An  Army  technical  memorandum  indicated  the  importance  of  the  operator’s  and  maintainer’s 
relationship  to  an  item  of  hardware. 

People  are  the  only  responsible  agents  in  the  system.  No  matter  how  small  the  roles  assigned  to 
people,  they  are  responsible  roles.  People  determine  whether  the  system  is  ready  to  operate,  what 
it  is  to  do,  how  and  when  it  is  to  do  it,  when  and  what  variations  in  performance  are  to  occur, 
and  what  constitutes  adequate  or  complete  performance.  People  decide,  control,  guide  change, 
and  evaluate.  They  are  expected  to  anticipate,  detect,  compensate  for,  and  explain  any  undesirable 
variations  in  performance.  And  their  errors  assume  a  significance  commensurate  with  their 
responsibilities. 

These  relatively  recent  reports  point  out  the  importance  of  the  human  being  as  a  system  component 
and  reiterate  problems  that  have  existed  as  long  as  human  beings  have  been  required  to  use  tools  to 
perform  work.  The  need  for  human  factors  as  a  discipline  escalated  during  World  War  II  when  the 
armed  forces  recruited  thousands  of  men  from  all  walks  of  life  anc'  faced  the  problems  of  training 
them  to  perform  unfamiliar  tasks  quickly  with  military  hardware. 
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SECTION  11 
HUMAN  FACTORS 


t 

11.1  INTRODUCTION 


11.1.1  References 

MIL-STD-1472  C,  Human  Engineering  Design  Criteria  for  Military  Systems,  Equipment  and 
Facilities,  2  May  1981 

MIL-H-46855B,  Human  Engineering  Requirements  for  Military  Systems,  Equipment  and 
Facilities,  21  January  1979 

Human  Factors  Design  Handbook ,  Wesley  E.  Woodson,  McGraw-Hill  Book  Company,  1982 
Air  Force  Logistics  Command,  Human  Factors  Engineering  Computer  Based  Instructional 
Course 

NOSC  TD  250,  Revision  A,  Suggestions  for  Designers  of  Navy  Electronic  Equipment,  May  1985 


11.1.2  Summary 

See  text.  Also  consider  the  words  of  Albert  Einstein,  “Concern  for  man  himself  and  his  fate  must 
always  form  the  chief  interest  of  all  technological  endeavors.” 


11.2  GENERAL 


Human  Factors,  Human  Engineering,  Human  Factors  Engineering,  Man-Machine  Interface, 
Human-Computer  Interface,  User-Computer  Interface,  Man-Machine  Technology,  Ergonomics.  These 
are  all  terms  that  are  used,  sometimes  interchangeably,  to  indicate  those  investigators  who  treat  the 
human  user  as  part  of  the  system  design  process.  Human  factors  engineering,  or  HFE,  is  the  practice 
of  designing  products  so  that  a  human  being  can  use  these  products  for  their  designed  purposes,  operate 
them  easily,  service  them,  and  support  them  in  situ.  All  of  this  should  be  accomplished  with  a  minimum 
of  stress  and  a  maximum  of  efficiency.  In  simple  terms,  human  factors  are  characteristics  of  people 
—  characteristics  such  as  size,  shape,  ability  to  see  and  hear,  strength,  intelligence,  temperament, 
forgetfulness,  and  weakness.  Such  characteristics  —  the  human  factors  —  must  be  taken  into  account 
so  that  human  beings  and  things  made  for  their  use  will  go  well  together. 


11.2.1  Purpose 


The  purpose  of  this  section  is  to  provide  NOSC  program  managers  with  an  understanding  of  the 
need  for  and  benefits  of  including  human  factors  expertise  as  part  of  the  program  design  team  and 
to  provide  some  useful  references  to  consult  for  answers  to  human  factors  questions. 
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11.2.2  Background 


A  report  by  the  Navy  Research  Advisory  Committee  on  Man-Machine  Technology  in  the  Navy, 
December  1980,  stated 

The  human  element  has  become  the  most  critical,  most  problematic  and  most  costly  component 
of  the  Navy.  Meanwhile,  increasingly  complex  hardware  systems  are  being  developed  and  procured 
for  Fleet  use. 

Given  present  trends,  the  Navy  will  find  itself  unabie  to  operate  and  maintain  its  systems,  in  either 
the  short  or  long  term,  with  the  numbers  of  skilled  personnel  necessary  for  effective  mission 
accomplishment. 

A  Report  to  the  Congress  of  the  United  States  by  the  Comptroller  General  in  January,  1981, 
“Effectiveness  of  U.S.  Forces  Can  Be  Increased  Through  Improved  Weapon  System  Design’ '  concluded 

There  are  indications  that  human  ineptitude  or  poor  human  reliability  may  cause  over  50  percent 
of  all  weapon  system  failures.  The  increasingly  complicated  nature  of  modern  military  systems 
together  with  internal  military  personnel  problems  suggests  that  human-induced  errors  both  in 
operations  and  maintenance  could  also  increase  unless  more  attention  is  paid  to  this  problem  during 
design  and  development.  Weapon  systems  designs  have  been  dictating  manpower  requirements. 
What  is  needed  is  a  continuing  interface  between  the  system  designers  and  the  manpower  planners 
with  manpower  requirements  influencing  system  design  and  vice  versa. 

If  the  design  of  systems  is  to  adequately  consider  all  the  human  limitations  (including  skill  levels, 
proficiency,  availability,  environmental  stress,  and  fatigue),  military  specifications,  standards,  and 
handbooks  must  address  these  factors.  Existing  documents  do  not.  Also,  common  methodologies 
and  sources  of  data  are  needed  to  forecast  skill  levels  of  potential  military  personnel  5  to  10  years 
in  the  future.  This  information,  which  would  be  extremely  valuable  to  system  designers  and  testers, 
is  currently  not  available. 

Finally,  there  does  not  appear  to  be  sufficient  emphasis  on  testing  systems  from  a  human  reliability 
standpoint  particularly  in  the  developmental  stages  of  the  acquisition  process.  This  could  result 
in  design  errors  requiring  expensive  modifications  after  the  system  is  deployed. 

An  Army  technical  memorandum  indicated  the  importance  of  the  operator’s  and  maintainer’s 
relationship  to  an  item  of  hardware. 

People  are  the  only  responsible  agents  in  the  system.  No  matter  how  small  the  roles  assigned  to 
people,  they  are  responsible  roles.  People  determine  whether  the  system  is  ready  to  operate,  what 
it  is  to  do,  how  and  when  it  is  to  do  it,  when  and  what  variations  in  performance  are  to  occur, 
and  what  constitutes  adequate  or  complete  performance.  People  decide,  control,  guide  change, 
and  evaluate.  They  are  expected  to  anticipate,  detect,  compensate  for,  and  explain  any  undesirable 
variations  in  performance.  And  their  errors  assume  a  significance  commensurate  with  their 
responsibilities. 

These  relatively  recent  reports  point  out  the  importance  of  the  human  being  as  a  system  component 
and  reiterate  problems  that  have  existed  as  long  as  human  beings  have  been  required  to  use  tools  to 
perform  work.  The  need  for  human  factors  as  a  discipline  escalated  during  World  War  II  when  the 
armed  forces  recruited  thousands  of  men  from  ail  walks  of  life  and  faced  the  problems  of  training 
them  to  perform  unfamiliar  tasks  quickly  with  military  hardware. 


JMl 


f  11-4 


\ 


While  human  beings  and  machines  have  been  around  for  a  long  time,  the  profession  of  human 
factors  engineer  is  relatively  young,  and  it  is  generally  made  up  of  people  from  varying  disciplines  such 
as  cognitive  and  industrial/'crganizational  psychology,  physiology,  engineering,  (all  types),  industrial 
design,  computer  science,  anthropology,  sociology,  systems  analysis,  biomechanics,  operations  research, 
and  business  and  management  science.  Human  factors  is  truly  an  interdisciplinary  profession  with  the 
common  purpose  of  enhancing  the  performance  of  the  entire  system  while  including  the  human  user 
as  an  integral  part  of  that  system  design. 

Human  factors  engineering  is  a  discipline  born  of  crisis.  After  every  system  failure  resulting  in 
catastrophic  loss,  from  World  War  II  pilots  mistaking  landing  gear  levers  for  throttles  to  the  Three 
Mile  Island  and  Chernobyl  nuclear  disasters  and  to  the  space  shuttle  explosion,  accident  investigators 
have  tried  to  pinpoint  the  causes  of  failure  and  in  many  instances  have  concluded  that  the  system  failed 
because  of  human  error.  Whenever  human  beings  are  part  of  the  system  there  will  be  human  errors. 
The  task  of  designers  is  to  predict  what  those  are  likely  to  be  and  take  appropriate  measures  to  preclude 
their  occurrence.  System  designers  are  most  successful  in  this  endeavor  when  they  adopt  a  human- 
centered  design  philosophy  and  enlist  the  aid  of  human  factors  experts.  The  tasks  of  the  human  factors 
engineer  are  then  to  (1)  evaluate  the  human  being  as  a  system  component  and  his  or  her  contribution 
to  the  total  system;  and  (2)  to  influence  the  selections  among  design  alternatives  as  they  relate  to  people. 


11.3  THE  HUMAN  BEING  AS  SYSTEM  COMPONENT 

In  evaluating  the  human  user  as  a  primary  system  component,  the  human  factors  engineer  will 
take  into  account  such  human  capabilities  as  the  following 

a.  Information  sensors 

b.  Information  processors 

c.  Response  mechanisms 

d.  Their  unique  properties  as  human  beings 

Human  beings  as  system  components  exhibit  variability  in 

a.  Dimensions 

b.  Perceptions 

c.  Reactions 

d.  Tolerances 

All  of  these  human  variables  are  well  documented  in  the  anthropometric  literature.  The  Human  Factors 
Design  Handbook  by  Woodson  has  several  chapters  devoted  to  the  subject.  However,  it  is  well  to  note 
that  even  among  “homogeneous”  populations,  for  example  all  Navy  males  between  17  and  24,  the 
range  of  dimensions  can  be  considerable.  Variability  is  usually  expressed  in  terms  of  percentiles.  Most 
designs  should  accommodate  a  wide  range,  generally  the  2nd  to  98th  or  5th  to  95th  percentile  ranges. 
A  piece  of  equipment  that  is  designed  for  the  “average”  reach,  the  50th  percentile,  will  be  out  of  reach 
for  50  percent  of  the  intended  users.  “Average”  is  a  statistical  term  which  applies  only  to  groups.  Most 
people  will  fall  into  the  “average”  range  on  only  a  few  variables. 

Variability  of  human  dimensions  can  best  be  handled  for  a  wide  range  of  people  by  employing 
adjustability.  There  are  certain  applications,  space  suits  for  example,  where  it  will  be  necessary  to 
customize  the  design  for  each  segment  of  the  population.  Designing  for  the  mythical  average  user  is 
sometimes  acceptable,  but  usually  is  preceded  by  extensive  research  and  iterative  design.  An  example 
of  a  design  for  an  average  user  might  be  a  telephone  or  computer  keyboard. 


When  designing  prototype  tests,  the  following  key  dimensions  in  human  performance  should  be 
considered 

a.  Speed  versus  accuracy 

b.  Skilled  versus  unskilled 

c.  Performance  standards  and  criteria 

d.  Hawthorne  effect  and  related  “artifacts” 

e.  Individual  differences 

f.  Training 

Performance  standards  and  criteria  should  be  specified  before  the  test  is  run.  The  use  of  control  and 
experimental  groups  of  subjects  should  be  the  rule,  otherwise  the  test  results  will  be  contaminated  by 
the  subjects  having  been  given  previous  training.  Training  effects  can  cause  confounding  of  test  results 
due  to  either  positive  or  negative  transfer  of  training.  An  example  of  positive  transfer  of  training  would 
be  the  elevated  score  on  a  word  processing  test  that  a  subject  who  had  previous  experience  on  a  typewriter 
might  obtain.  Negative  transfer  of  training  would  occur  if  a  person  had  been  trained  to  operate  a  shift 
lever  with  his/her  left  hand  and  the  new  design  required  right  hand  operation. 

The  Hawthorne  effect  is  named  after  some  studies  that  were  done  in  an  industrial  plant  in 
Hawthorne,  Pennsylvania,  some  years  ago.  Researchers  told  factory  workers  that  they  were  studying 
productions  rates  and  that  certain  workers  would  be  selected  to  participate.  They  observed  that  production 
rates  went  up  even  without  making  any  changes  to  the  workers  environment.  In  fact,  when  lighting 
was  increased,  production  went  up,  and  when  lighting  was  decreased  production  also  went  up.  The 
moral  of  this  story  is  that  certain  behaviors  may  occur  merely  because  people  are  aware  that  they  are 
being  watched.  Human  factors  engineers  will  be  able  to  help  design  tesis  to  guard  against  such  artifacts 
and  avoid  wasted  time  and  money. 

11.4  OPTIMUM  SYSTEM  PERFORMANCE 

System  performance  is  defined  as  the  interaction  between  human  behavior  and  the  performance 
of  nonhuman  system  elements  such  as  equipment,  procedures,  and  environmental  support  facilities. 
Human  behavior  in  the  system  includes  not  only  the  human  operator  or  user,  but  the  behavior  of  those 
others  who  have  to  maintain  the  system  in  operable  condition  and  still  others  who  are  involved  in 
developing  the  various  supporting  documents  and  equipment  and  the  training  courses  and  materials. 
It  is  well  to  note  that  improvements  in  human  performance  may  or  MAY  NOT  affect  system  performance. 
Therefore,  systems  design  is  creating  optimum  system  performance  by  matching  and  integrating  people, 
processes,  and  materials  . . .  not  necessarily  optimizing  all  three  factors. 

11.5  BENEFITS  OF  HUMAN  FACTORS  ENGINEERING 

When  human  factors  concerns  are  identified  early  in  the  design  cycle  and  appropriate  alternatives 
are  selected  with  the  user  in  mind  as  an  integral  system  component,  the  resultant  benefits  include  the 
following 

a.  Increased  productivity  and  performance 

b.  Minimized  operator  stress  and  error 


c.  Reduced  skill  level  requirements 

d.  Improved  system  reliability 

e.  Improved  marketability  and  longevity 

The  consequences  of  not  considering  human  factors  issues  during  system  design  can  be  disastrous  because 
human  errors  are  inevitable  as  long  as  humans  are  operators,  maintained,  and  trainers.  Human 
capabilities  do  not  equal  human  char  .cteristics.  The  fact  that  humans  are  capable  of  discerni.  _•  *  arning 
light  or  alarm  does  not  guarantee  that  they  will  take  any  action  if  false  alarms  are  frequent.  Human 
adaptation  is  never  free;  it  always  comes  at  some  cost  that  may  not  be  the  concern  of  the  program 
manager,  but  ultimately  will  contribute  to  the  system  total  life-cycle  costs  by  requiring  expensive  retrofits, 
special  support  equipment,  additional  training,  or  production  of  additional  spare  parts.  While  it  is 
true  that  people  are  the  most  flexible  element  in  system  design,  they  are  the  most  difficult  to  redesign. 
The  costs  of  poor  design  are  tremendous  in  terms  of  personnel  selection,  training,  and  adaptability. 


11.6  HFE  METHODOLOGICAL  TOOLS  AND  DESIGN  AIDS 

In  addition  to  the  human  perception,  reaction,  tolerance,  and  anthropometric  databases  that  human 
factors  experts  have  compiled  over  the  years,  there  are  other  specific  methodological  tools  that  are 
employed  to  identify  human  factors  issues  in  system  design. 

Task  analysis  is  a  means  of  breaking  down  operations  into  smaller  units  in  order  to  determine 
whether  those  functions  should  be  correctly  allocated  to  the  human  user  or  should  be  automated. 

Job  analysis  is  a  means  of  determining  how  many  tasks  are  incorporated  into  each  job  unit  and 
then  taking  a  critical  look  at  the  tasks  within  each  job  to  determine  whether  or  not  it  is  beneficial  to 
both  human  beings  and  the  system  to  group  tasks  that  way. 

Systems  analysis  is  a  means  of  looking  at  the  entire  system,  including  the  human  user’s  contribution, 
to  determine  how  all  parts  of  the  system  work  together,  whether  any  part  is  overloaded  or  underused, 
and  especially  to  consider  the  affects  of  those  system  components  that  have  been  heretofore  neglected. 

Human  performance  research  is  being  carried  out  at  many  government  and  private  laboratories 
throughout  the  country  and  the  world.  This  research  unfortunately  lags  behind  recent  technological 
leaps,  especially  in  the  user-computer  interface  realm.  Researchers  may  be  involved  in  testing  prospective 
users  on  particular  aspects  of  user-interface  design  for  something  like  a  new  radar  operator’s  work 
station  or  they  may  be  doing  more  basic  research  into  generic  questions;  for  example,  in  determining 
whether  a  trackball  or  a  mouse  provides  the  user  with  more  positive  feedback  and  control.  With  the 
vast  diversity  in  equipment  and  systems  being  designed  just  in  the  Navy,  it  is  unlikely  that  any  design 
will  be  able  to  get  by  without  having  some  human  performance  research  done.  On  the  other  hand, 
there  is  a  large  body  of  published  literature  on  experiments  that  have  already  been  performed,  so  it 
will  not  be  necessary  in  most  cases  to  do  basic  research,  but  will  be  possible  to  build  on  the  results 
already  achieved  by  others  to  shorten  the  amount  of  necessary  human  performance  testing. 

Standards,  criteria,  and  checklists  are  often  most  helpful.  A  list  of  the  more  pertinent  of  these 
to  Navy  systems  is  included  under  the  reference  section.  A  few  tables  and  a  questionnaire  are  included 
at  the  end  of  this  article  to  aid  designers  in  allocation  of  function  and  ensure  they  have  addressed  all 
of  the  major  human  factors  issues. 

The  last  of  the  tools  and  design  aids  is  anecdotal  wisdom.  This  category  takes  in  all  the  knowledge 
that  has  been  gathered  too  recently  to  appear  in  publication,  maybe  as  recently  as  the  last  project  the 
human  factors  engineer  worked  on.  HFE  people  generally  keep  informed  about  the  latest  developments 
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by  attending  conferences,  reading  periodicals,  talking  to  colleagues,  and  doing  their  own  research.  This 
category  has  taken  on  added  significance  with  the  explosion  in  new  features  being  invented  almost 
daily  for  computer  users. 


11.7  ALLOCATION  OF  FUNCTION  OR  WHO  DOES  WHAT? 

After  performing  a  task  analysis  it  will  be  necessary  to  make  some  decisions  about  allocating 
functions  either  to  the  human  user  or  to  some  other  system  component.  In  making  these  decisions, 
designers  must  consider  what  people  WILL  do  (characteristic  performance),  not  what  they  can  do 
(capability).  Keep  in  mind  the  example  of  false  alarms  already  discussed.  Most  contemporary  decisions 
involve  the  LEVEL  and  NATURE  of  semiautomation  that  is  appropriate  as  opposed  to  traditional 
manned  versus  unmanned  systems.  The  space  shuttle  was  uniquely  qualified  to  put  people  in  orbit, 
sustain  life  while  certain  tasks  could  be  carried  out,  and  safely  return  to  the  earth.  It  was  an  almost 
ideal  testbed  for  zero-G  experimentation.  The  fact  that  it  could  also  launch  satellites  contributed  to 
the  decision  to  develop  an  ambitious  launch  schedule  to  help  it  “pay  its  way.’’  A  much  better  decision 
in  the  case  of  satellite  launch,  as  it  now  appears,  would  have  been  to  allocate  that  function  to  an  unmanned 
spacecraft.  Likewise,  for  many  other  less  sophisticated  systems,  the  fact  that  it  is  possible  for  either 
a  machine  or  a  human  being  to  perform  a  function  does  not  necessari'y  require  it.  The  information 
included  in  the  Appendix  of  this  section  compares  and  contrasts  human  and  machine  capabilities  and 
limitations  and  should  be  used  to  help  decide  who  ultimately  does  what. 


11.8  CONCLUSION 

Human  factors  engineering,  encompassing  a  body  of  knowledge  about  human  behavior  in  systems, 
is  a  multidisciplinary  field  that  advocates  enhancing  system  performance,  while  including  the  human 
user  as  a  primary  system  component,  and  provides  tools  and  design  aids  to  assist  system  designers 
in  identifying  and  overcoming  human  factors  problems. 

All  this  effort  has  still  not  succeeded  in  solving  all  the  problems.  System  designers  should  be  aware 
of  some  of  the  lingering  and,  perhaps,  eternal  problems  listed  here. 

11.8.1  Problems  with  Users 


a.  Don’t  care  about  the  elegance,  sophistication,  or  complexity  of  the  design  —  only  what  it 
can  (or  can’t)  do  for  them 

b.  Will  do  the  unexpected 

c.  Will  base  their  conception  of  the  system  or.  inadequate  knowledge 

d.  Won’t  ask  for  help  when  they  need  it 

e.  Will  fail  to  observe  the  prominently  displayed  instructions 

f.  Quickly  develop  habits  that  are  hard  to  change 


11.8.2  Problems  with  Engineers 


a.  They  assume  too  much  about  users. 

b.  They  tend  to  focus  on  hardware-oriented  system  criteria  (e.g.,  processing  speed). 

c.  They  “get  attached”  to  hardware  (also  software). 

d.  Many  will  never  use  the  systems  that  they  design. 

e.  They  are  suspicious  of  “soft”  sciences  like  psychology  (this  isn’t  always  inappropriate!). 

11.8.3  Problems  with  Behavioral  Scientists 

a.  Research  reports  often  lack  design-relevant  interpretations  and  recommendations. 

b.  Laboratory  studies  may  not  generalize  to  an  operational  context. 

c.  Lack  of  familiarity  with  hardware  systems  can  lead  to  the  study  of  “unreal”  variables. 

d.  Obsession  with  advanced  statistical  methods  can  lead  to  intense  scrutiny  of  trivial  factors. 

11.8.4  Still  More  Problems 

a.  Standards  are  adopted  for  political  reasons. 

b.  Economic  incentives  often  promote  the  status  quo. 

c.  There  is  a  tendency  to  translate  old  concepts  and  models  to  new  technology  (this  can  be  limiting). 

d.  Creative  problem-solving  requires  diverse  backgrounds,  including  people  who  know  LITTLE 
OR  NOTHING  ABOUT  THE  TECHNICAL  LIMITATIONS. 

e.  “Implicit  assumptions”  can  plague  otherwise  excellent  designs. 

11.8.5  The  Final  Word 

Successful  system  design  places  early  focus  on  users  and  tasks,  employs  empirical  measurements 
of  human  performance,  and  iterates  the  design  in  order  to  achieve  optimum  system  performance.  Human 
factors  expertise  should  be  applied  in  system  planning,  system  design  and  implementation,  system 
evaluation,  and  system  modification.  Unfortunately,  human  factors  are  often  applied  only  where 
government  requires  it,  or  too  early  in  system  planning,  or  too  late  in  system  design,  or,  the  ultimate, 
when  everything  else  has  been  tried.  There  are  enough  stories  circulating  about  equipment  poorly 
designed,  inoperable,  unsupportable,  lacking  standardization,  with  poor  accessibility,  and  poor  man- 
machine  interface  to  keep  human  factors  experts  going  for  years  trying  to  clear  up  the  problems.  The 
alternative  is  for  system  designers  and  program  managers  to  avail  themselves  of  the  human  factors 
expertise  resident  at  NOSC  to  ensure  that  they  will  become  one  of  the  success  stories.  Or,  in  the  words 
of  that  preeminent  scientist,  Albert  Einstein, 

Concern  for  man  himself  and  his  fate  must  always  form  the  chief  interest  of  all  technological 
endeavors. 


Appendix  11 A 


Auxiliary  Human  Factors  Information 


The  following  items  are  included  in  the  Appendix: 

Human  Factors  Engineering  (HFE)  Computer-Based  Instructual  (CBI)  Course 
Log-On  Procedures  for  Introduction  to  Human  Factors  Engineering 

Human  Factors  in  Engineering  and  Design,  Ernest  J.  McCormick,  McGraw-Hill,  Inc.,  1976 
(an  excerpt) 

Human  Limitations  and  Machine  Alternatives 
Allocation  of  Function/Allocation  of  Function  Procedures 


HUMAN  FACTORS  ENGINEERING  (HFE) 
COMPUTER-BASED  INSTRUCTIONAL  (CBI)  COURSE 


The  HFE  CBI  course  is  an  adaptation  of  the  ARMY/NAVY  self-paced  HFE  text  developed  by 
Brogan,  et.  al.,  of  the  ARMY  HEL  in  1981. 

The  course  objectives  are 

1.  An  understanding  of  common  HFE  terms 

2.  An  awareness  of  sources  of  HFE  information 

3.  An  ability  to  integrate  HFE  into  a  development  or  modification  program  with  minimum 
guidance  and  direction  from  experienced  HFE  personnel 

4.  An  ability  to  determine  HFE  requirements 

5.  An  understanding  of  the  kinds  of  factors  and  forces  which  affect  human  performance 

6.  An  awareness  of  HFE  test  methods 

7.  An  awareness  of  human  performance  reliability  factors 

8.  An  awareness  of  time  and  error  performance  measures 

9.  An  understanding  of  the  major  HFE  techniques 

10.  A  familiarity  with  task  analyses 

11.  An  awareness  of  the  relationship  between  HFE  and  reliability 

12.  An  ability  to  apply  HFE  standards,  specifications,  and  references 

NONPROPRIETARY  SOFTWARE 

The  applications  software  is  wholly  developed  and  owned  by  the  Air  Force  Logistics  Command. 
There  is  nothing  proprietary  in  the  software.  Therefore,  it  can  be  provided,  free,  to  any  DoD  agency 
that  finds  a  need  to  implement  CBI  courseware.  Given  the  currently  high  licensing  fees  for  commercially 
available  CBI  software,  our  CBI  software  may  be  able  to  save  one  of  your  development  programs 
a  considerable  amount  of  money. 

COURSE  WORK 

The  course  can  be  accessed  by  almost  any  computer  terminal  that  has  a  300  or  1200  BAUD  telephone 
modem.  As  long  as  our  computer  resources  are  not  overbooked  by  too  many  students,  we’ll  provide 
an  accessible  HFE  CBI  course  for  all  DoD  personnel  and  contractors  with  active  DoD  contracts.  The 
phone  company,  however,  will  charge  you  for  a  commercial  long  distance  phone  call  if  you  use  a 
commercial  long  distance  line  to  hook-up  your  modem. 


LOG-ON  PROCEDURES  FOR 
INTRODUCTION  TO  HUMAN  FACTORS  ENGINEERING 

These  instructions  explain  procedures  to  access  the  HFE  self-paced  course  on  the  AFLC  computer. 
Almost  any  computer  terminal  can  be  used  as  a  dumb  terminal  to  access  the  course.  Most  terminals 
have  switches  on  them  that  can  be  set  to  various  configurations.  Your  terminal  must  be  configured  with 

BAUD  RATE  300  OR  1200  (ASYNCHRONOUS  LINE) 

DUPLEX  HALF  (OR  FULL  IF  SELF  ECHO  IS  ON) 

PARITY  EVEN 

CARRIAGE  RETURN  WITHOUT  LINE  FEED 

CHARACTER  TYPE  7  BIT  ASCII  PLUS  1  BIT  EVEN  PARITY,  1  START  BIT, 

1  STOP  BIT 

Phone  the  AFLC  computer  at 

1200  BAUD  RATE  LINE  —  AV  787-8243  or  COMMERCIAL  (513)  257-8243 

300  BAUD  RATE  LINE  —  AV  787-8247/53/57/65  or  COMMERCIAL  (513)  257-8247/53/57 

After  the  carrier  tone  is  present  on  the  phone  line  and  the  telephone  receiver  is  connected  to  your 
computer  modem,  you  must  enter  each  of  the  following  commands  with  a  carriage  return  after  each  one: 

WHEN  THE  COMPUTER  DISPLAYS,  THEN  THE  STUDENT  ENTERS: 

?  ZW„TSS  (or  use  VD„TSS) 

USER  ID—  HUMANSFACTORS 

PROBLEM  NUMBER-  WP1906 

*  FRN  HFE/TUTOR.E 

It  is  important  that  the  above  commands  are  entered  exactly  as  shown  above,  that  is,  do  not  insert 
spaces  where  none  are  shown.  Use  the  @  symbol  to  internally  delete  characters  that  you  have  misspelled. 

After  entering  the  last  command  above,  the  computer  will  require  about  20  to  40  seconds  to  load 
and  compile  the  program.  Then,  the  computer  will  lead  you,  step  by  step,  through  the  self-paced  course 
by  listing  information  to  you  and  asking  questions. 

If  you  use  an  autovon  line  to  link  your  terminal  to  the  AFLC  computer,  it  is  always  subject  to 
interruption.  If  this  occurs,  the  computer  will  remember  where  you  were  in  the  lesson  and  will  restart 
you  at  the  point  that  you  were  interrupted.  Have  patience  and  start  the  above  log-on  procedure  again. 
Use  a  commercial  phone  line  if  problems  with  autovon  persist. 

Your  organi.  ation  will  not  be  charged  for  the  AFLC  computer  time.  The  course  is  free  to  all  DoD 
employees  and  contractor  personnel  with  active  DoD  contracts.  The  phone  company,  however,  will 
charge  you  for  a  commercial  line,  if  used.  A  training  certificate  will  be  sent  to  you  when  you  finish 
all  the  lessons. 

To  exit  the  program: 

For  teletype  terminals,  depress  the  interrupt  button  and  follow  the  instructions  that  are  listed  to  you. 

For  CRT  terminals,  enter  the  letter  B  whenever  a  question  is  asked  of  you.  Then  follow  the 
instructions  that  are  listed  to  you. 

IF  YOU  HAVE  PROBLEMS,  CONTACT  NAT  DAVIS  -  AV  787-5571  OR  (513)  275-5571. 


Human  Factors  in  Engineering  and  Design, 

Ernest  J.  McCormick,  McGraw-Hill  Inc.,  1976  (an  excerpt) 

The  questions  given  below  should  be  viewed  as  they  would  be  relevant  to  the  ultimate  user 
population.  The  fulfillment  of  one  objective  may  of  necessity  be  at  the  cost  of  another. 

In  a  general  sense  these  questions  may  serve  as  “reminders”  of  some  of  the  human  factors 
considerations  that  should  be  taken  into  account  in  the  design  process. 

1.  What  are  the  functions  that  need  to  be  carried  out  to  fulfill  the  system  objective? 

2.  If  there  are  any  reasonable  options  available,  which  of  these  should  be  performed  by  human 
beings? 

3.  For  a  given  function,  what  information  external  to  the  individual  is  required?  Of  such 
information,  v'hat  information  can  be  adequately  received  directly  from  the  environment, 
and  what  information  should  be  presented  through  the  use  of  displays? 

4.  For  information  to  be  presented  by  displays,  what  sensory  modality  should  be  used? 
Consideration  should  be  given  to  the  relative  advantages  and  disadvantages  of  the  various 
sensory  modalites  for  receiving  the  type  of  information  in  question. 

5.  For  any  given  type  of  information,  what  type  of  display  should  be  used?  The  display  generally 
should  provide  the  information  when  and  where  it  is  needed.  These  considerations  may  take 
into  account  the  general  type  of  display,  the  stimulus  dimension  and  codes  to  1  .  used,  and 
the  specific  features  of  the  display.  The  display  should  provide  for  adequate  sensory 
discrimination  of  the  minimum  differences  that  are  required. 

6.  Are  the  various  visual  displays  arranged  for  optimum  use? 

7.  Are  the  information  inputs  collective*^  within  the  reasonable  bounds  of  human  information¬ 
receiving  capacities? 

8.  Do  the  various  information  sources  avoid  excessive  time-sharing? 

9.  Are  the  decisionmaking  and  adaptive  abilities  of  human  beings  appropriately  utilized? 

10.  Are  the  decisions  to  be  made  at  any  given  time  within  the  reasonable  capability  limits  of 
human  beings? 

11.  Granting  that  aspects  of  some  systems  will  be  automated,  is  the  basic  control  of  the  system 
that  o  ■  the  individual? 

12.  When  physical  control  is  to  be  exercised  by  an  individual,  what  type  of  control  device  should 
be  used? 

13.  Is  each  control  device  easily  identifiable? 

14.  Is  the  operation  of  each  control  device  compatible  with  any  corresponding  display,  and  with 
common  human  response  tendencies? 

15.  Are  the  operational  requirements  of  any  given  control  (as  well  as  of  the  controls  generally) 
within  reasonable  bounds?  The  requirements  for  force,  speed,  precision,  etc.,  should  be  within 
limits  of  virtually  ail  persons  who  are  to  use  the  system.  The  man-machine  dynamics  should 
so  capitalize  on  human  abilities  that,  in  operation,  the  devices  meet  the  specified  system 
requirements. 


16.  Are  the  control  devices  arranged  conveniently  and  for  reasonably  optimum  use? 

17.  If  there  is  a  communication  network,  will  the  communication  flow  avoid  overburdening  the 
individuals  involved? 

18.  Are  the  various  tasks  to  be  done  grouped  appropriately  into  jobs? 

19.  Do  the  tasks  which  require  time-sharing  avoid  overburdening  any  individual  or  the  system? 
Particular  attention  needs  to  be  given  to  the  possibility  of  overburdening  in  emergencies. 

20.  Is  there  provision  for  adequate  redundancy  in  the  system,  especially  of  critical  functions? 
Redundancy  can  be  provided  in  the  form  of  backup  or  parallel  components  (either  men  or 
machines). 

21 .  Are  the  jobs  of  such  a  nature  that  the  personnel  to  perform  them  can  be  trained  to  do  them? 

22.  If  so,  is  the  training  period  expected  to  be  within  reasonable  time  limits? 

23.  Do  the  work  aids  and  training  complement  each  other? 

24.  If  training  simulators  are  used,  do  they  achieve  a  reasonable  balance  between  transfer  of 
training  and  costs? 

25.  Is  the  work  space  suitable  for  use  by  the  range  of  individuals  who  will  use  the  facility? 

26.  Are  the  environmental  conditions  (temperature,  illumination,  noise,  eic.)  such  that  they  permit 
satisfactory  levels  of  human  performance  and  provide  for  the  physical  well-being  of 
individuals? 

27.  In  any  evaluation  or  test  of  the  system  (or  components)  does  the  system  performance  meet 
the  desired  performance  requirements? 

28.  Does  the  system  in  its  entirety  provide  reasonable  opportunity  for  the  individual(s)  involved 
to  experience  some  form  and  degree  of  self-fulfillment  and  to  fulfill  some  of  the  human  values 
that  we  should  all  like  to  have  the  opportunity  to  fulfill  in  our  daily  lives? 

29.  Does  the  system  in  its  entirety  contribute  generally  to  the  fulfillment  of  reasonable  human 
values?  In  the  case  of  systems  with  identifiable  outputs  of  goods  and  services,  this  consideration 
would  apply  to  those  goods  and  services.  In  the  case  of  systems  that  relate  to  our  life  space 
and  everyday  living,  this  consideration  would  apply  to  the  potential  fulfillment  of  those  human 
values  that  are  within  the  reasonable  bounds  of  our  civilization. 

In  the  resolution  of  these  and  other  kinds  of  human  factors  considerations,  one  should  draw  upon 
whatever  relevant  information  is  available.  This  information  can  be  of  different  types,  including  principles 
that  have  been  developed  through  experience  or  research,  sets  of  normative  data  (such  as  frequency 
distributions  of,  say,  body  size),  sets  of  factual  data  of  a  probability  nature  (such  as  percentage  of 
signals  that  are  detected  under  specified  conditions),  mathematical  formulas,  tentative  theories  of 
behavior,  hypotheses  that  have  been  suggested  by  research  investigations,  and  even  the  general  knowledge 
acquired  through  everyday  experience. 
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HUMAN  LIMITATIONS  AND  MACHINE  ALTERNATIVES 


HUMAN 


Is  a  poor  monitor  of  infrequent  events  or  of  events 
which  occur  over  a  long  period  of  time 


Has  a  limited  channel  capacity 


Is  subject  to  coriolis  effects,  motion  sickness, 
disorientation,  etc. 


Has  extremely  limited  short-term  memory  for 
factual  material 


Is  not  well  suited  to  data  coding,  amplification, 
or  transformation  tasks 


Performance  is  degraded  by  fatigue  and  boredom 


Performance  is  degraded  by  long  duty  periods, 
repetitive  tasks,  and  cramped  or  unchanged 
positions 


Becomes  saturated  quickly  in  terms  of  the  number 
of  things  that  can  be  done  and  the  duration  of 
the  effort 


May  introduce  errors  by  misidentification, 
reintegration,  or  ciosure 

Expectation  or  cognitive  set  may  lead  an  operator 
to  see  what  he  or  she  expects  or  wants  to  see 

Much  human  mobility  is  predicated  and  based  on 
gravity  relationships 

Is  adversely  affected  by  g  forces 


Can  generate  only  relatively  small  forces  and  can¬ 
not  exert  large  forces  for  very  long  or  very 
smoothly 


Generally  requires  a  review  or  rehearsal  period 
before  making  decisions  based  on  items  in 
memory 

When  performing  a  tracking  task,  requires  fre¬ 
quent  reprogramming;  does  best  when  changes  are 
under  3  rad/s 


Has  a  build-;n  response  latency  of  about  200ms 
in  a  go-no-go  situation 


MACHINE 


Can  be  constructed  to  detect  infrequent  events  or 
events  which  occur  frequently  over  a  long  period 
of  time  reliably 


May  have  as  much  channel  capacity  as  can  be  af¬ 
forded 


Is  not  subject  to  these  effects 


May  have  as  much  short-term  (buffer)  memory 
as  can  be  afforded 


Is  well  suited  to  these  tasks 


Performance  is  degraded  only  by  wearing  out  or 
by  lacking  of  calibration 


Is  less  affected  by  long  duty  periods  and  performs 
repetitive  tasks  well;  some  may  be  restricted  by 
position 


Can  do  one  thing  at  time  so  fast  that  it  seems  to 
do  many  things  at  once,  for  a  long  period  of  time 


Uses  these  processes 


Does  not  exercise  these  processes 


May  be  built  to  perform  independently  of  gravity 


Is  unaffected  by  g  forces 

Can  generate  and  exert  forces  as  needed 


Goes  directly  to  stored  information  for  a  decision 


Has  no  such  limitations 


Has  no  response  latency 


From  Woodson  (1982) 
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ALLOCATION  OF  FUNCTION  (Page  1  of  2) 


Who  Does  What? 

Must  consider  what  people  WILL  do  (characteristic  pe-f  -rmance),  not  what  they  can  do  (capability) 
Most  contemporary  decisions  involve  the  LEVEL  and  NATURE  of  semiautomation  that  is  appropriate 


as  opposed  to  traditional  manned  versus  unmanned  systems 


ALLOCATION  OF  FUNCTION  PROCEDURES 
Comparison  of  Human  Capabilities  With  Machine  Alternatives 


HUMAN 


Can  recognize  and  use  information  redundancy 
(pattern)  in  the  real  world  to  simplify  complex 
situations 


MACHINE 

Has  limited  perceptual  constancy  and  is  very 
expensive 


Has  high  tolerance  for  ambiguity,  uncertainty, 
and  vagueness 


Can  interpret  an  input  signal  even  when  subject 
to  distraction,  noise,  or  message  gap 


Is  a  selecting  mechanism  and  can  adjust  to  sense 
specific  inputs 


Has  very  low  absolute  thresholds  for  sensing  (e.g. 
vision,  audition,  and  touch) 

Has  excellent  long  term  memory  for  related  events 


Can  become  highly  flexible  in  terms  of  task 
performance 


Is  highly  limited  by  ambiguity  and  uncertainty  in 
input 

Performs  well  only  in  a  generally  clean,  noise-free 
environment 

Is  a  fixed  sensing  mechanism,  operating  only  on 
that  which  has  been  programmed  for  it 

To  have  the  same  capability,  becomes  extremely 
expensive 

To  have  the  same  capability,  becomes  extremely 
expensive 

Is  relatively  inflexible 


Can  improvise  and  exercise  judgment  on  the  basis 
of  long  term  memory  and  recall 


Cannot  do  this;  is  best  at  routine,  repetitive 
functions 


Can  perform  under  transient  overload; 
performance  degrades  gracefully 


Stops  under  overload;  often  fails  all  at  once 


Can  make  inductive  decisions  in  novel  situations: 
can  generalize 


Has  little  or  no  capability  for  induction  or 
generalization 


Can  modify  performance  as  a  function  of 
experience;  can  “learn  to  learn” 


Is  not  characterized  by  trial-and-error  behavior 


Can  override  own  actions,  should  the  need  arise 


Is  reasonably  reliable;  can  add  reliability  to  system 
performance  by  selection  of  alternatives 


Can  do  only  what  it  is  built  to  do 

Is  reliable  only  at  the  expense  of  increased 
complexity  and  cost,  and  then  only  for  routine 
functions 


Complements  the  machine,  that  is,  can  use  it  in 
spite  of  design  failures,  can  use  it  for  a  different 
task,  or  can  use  it  more  efficiently  than  it  was 
designed  to  be  used 


Has  no  such  capability 
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HUMAN  MACHINE 

Complements  the  machine  by  aiding  in  sensing,  Has  no  capacity  for  performance  different  from 

extrapolating,  decisionmaking,  goal  setting,  what  was  originally  designed 

monitoring,  and  evaluating 

Can  acquire  and  report  information  incidental  to  Cannot  do  this 
the  primary  mission 

Can  perform  time-contingency  analyses  and  Does  very  poorly  at  this 

predict  events  in  unusual  situations 

Is  relatively  inexpensive  for  corresponding  Is  more  limited  in  terms  of  complexity  and  supply 

complexity  and  is  generally  in  good  supply,  but  by  cost  and  time 

must  be  trained 

Is  light  in  weight  and  small  in  size  for  function  To  have  functional  equivalence  of  the  human, 
achieved  for  most  situations  requires  more  weight,  power,  and  cooling  facilities 

Is  relatively  easy  to  maintain,  demands  a  Maintenance  problems  become  disproportionately 

minimum  of  “in-task”  extras  serious  as  complexity  increases 


From  Woodson  (1982) 
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SECTION  12 
DESIGN  REVIEW 


12.1  INTRODUCTION 

12.1.1  References 

NOSC  TD  8?0,  Product  Assurance  Program  Requirements 
NOSCINST  4855.1,  NOSC  Product  Assurance  Program 
NAVMATINST  3000.1  A,  Reliability  of  Naval  Material 
NOSCINST  3912.1,  Design  Review  Committee 

12.1.2  Summary 

This  section  explains  NOSC’s  design  review  policies  and  states  Center  policy  relative  to  design 
app'oval  and  release  of  NOSC-developed  components,  subsystems,  systems,  and  major  items  cf  system 
software. 


12.2  DESIGN  REVIEW  GOALS 

The  primary  goal  of  the  design  review  process  is  to  ascertain  that  the  development  programs  at 
the  Center  have  a  high  probability  of  success  in  meeting  their  technical  ret  irements  and  will  be 
operationally  effective  and  sustainable  when  delivered  to  the  Fleet.  The  process  is  provided  to  assist 
the  program  manager  in  this  regard.  In  addition,  these  independent  reviews  will  provide  the  basis  for 
advice  to  the  technical  director  on  all  technical  and  material  matters  of  concern  pertaining  to  the 
development,  operation,  and  production  of  a  component,  subsystem,  system,  or  major  item  of  system 
software,  developed  by  and  which  is  the  responsibility  of  the  Center,  for  decisions  related  to  the  Fielding 
of  the  product.  The  design  review  committee  will  also  provide  this  function  in  those  instances  where 
the  Center  acts  as  design  agent  or  technical  direction  agent  or  has  other  major  design  responsibility 
for  systems  or  subsystems.  The  committee  will  also  provide  this  function  in  those  instances  where  the 
Center  has  other  significant  responsibilities  related  to  the  use  of  unproven  items  as,  for  example,  in 
operational  exercises  or  scientific  sea  tests.  Figure  12.1  offers  a  sample  outline  for  a  major  system 
presentation. 


12.3  PRODUCT  ASSURANCE 

Guidance  and  reference  material  related  to  the  NOSC  product  assurance  program  are  provided 
in  NOSCINST  4855.1  and  NOSC  TD  870. 
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12.4  TYPES  OF  REVIEWS 

NAVMATINST  3000.1A  states  that,  at  a  minimum,  the  design  reviews  shall  include  preliminary 
design  review  (PDR)  of  the  design  approach  prior  to  initiation  of  detailed  design;  a  critical  design  review 
(CDR)  of  the  detailed  design  prior  to  drawing  release  and  fabrication  of  formal  test  articles;  a  design 
certification  review  (DCR)  of  the  final  design  subsequent  to  qualification  testing  and  prior  to  Navy 
operational  test  and  evaluation  and  production  start;  and  a  final  production  review  (FPR)  at  the  time 
of  a  first  article  configuration  inspection  (FACI)  of  the  as-produced  design  following  manufacture 
and  acceptance  testing  of  the  first  end  item  configured  for  delivery  to  the  Fleet.  If  standard  reviews 
are  conducted  by  the  sponsor  as  part  of  the  system  development  process,  the  design  reviews  are  in 
concert  with  these  scheduled  reviews.  Figure  12.2  indicates  timing  of  reviews  within  the  major  systems 
acquisition  cycle. 


12.4.1  Mand-'^ry  Reviews 


All  major  acquisition  programs  require  mandatory  reviews.  These  include  development  of  large 
systems  with  many  components  destined  for  large  production  numbers  and  eventual  long  life  in  the 
Fleet  (e.g.,  MK  50  torpedo,  MILSTAR  SATCOM). 

All  man-machine  interfaced  programs  involving  safety  considerations  require  mandatory  reviews. 

All  hardware/software/firmware  systems  leaving  NOSC  for  installation  supporting  any  DoD 
activity,  even  for  ?  limited  installation  period,  also  require  mandatory  reviews. 


12.4.2  Negotiable  Reviews 
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Reviews  are  negotiable  for  minor  systems  or  feasibility  models  designed  for  limited  production. 
Minor  systems  include  smaller  systems  with  fewer  components  for  feasibility  demonstration  or  limited 
production  that  may  still  have  long  life  in  the  Fleet,  for  example,  AUSS  (Advanced  Undersea  Search 
System),  SLC  (Submarine  Laser  Communication)  system,  and  Advanced  Combat  Direction  System 
(ACDS). 

Reviews  are  also  negotiable  for  nondeliverable  demonstration  testbeds. 

12.4.3  Reviews  Not  Required 


Test  instrumentation 
Nondeliverable  test  hardware 
Nondeliverable  experimental  devices 
Minor  support  equipment 

12.5  RESPONSIBILITIES 
12.5.1  Department  Head 


It  is  the  responsibility  of  every  department  head  to  identify  in  a  timely  way  those  components, 
subsystems,  systems,  and  major  items  of  software  that  must  undergo  design  review. 
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INTRODUCTION 


Purpose  of  Review 

BACKGROUND 

Operational  Requirement 
Program  Summary  WBS  (Sponsor’s) 

Narrative  System  Description 
Frogram  Objectives 
System  Performance 
Cost 
Schedule 

Management  Approach  (Sponsor’s) 

Program  Plan 
Acquisition  Plan 
Delegation  of  Responsibilities 

-  Sponsor 

-  Contractors 

-  Centers/Labs/etc. 

-  NOSC 

-  Tasking  Documents 

-  Interface  Agreements,  Work  Agreements 
MANAGEMENT  OVERVIEW 

Subprogram  WBS  (NOSC) 

Organization 

Accountability  Matrix  (WBS  vs  Organization  Chart) 
Assignments  of  Responsibility 
Management  Practices 
Planning 
Reporting 

Cost/Schedule  Tracking  and  Analysis 
Design  Review  Schedule 
Management  Review  Schedule 
Schedule 

Milestone  Objectives 
Budget 
Fiscal 

Current 
Out  Years 
Manpower 

Total  and  by  Departments 
Other  Resources 
Procurement  Plans/Status 
Subsystems 
Components 
Support/Services 


Figure  12.1.  Sample  outline  for  a  major  system  presentation  (1  of  2). 
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TECHNICAL  PROGRAM 


System  Engineering 

System  Requirements  (Specifications) 

Performance 

Environmental 

Life-Cycle  Profile 
System  Level 
System  Functions 

Functional  Allocations 
Subsystem  Requirements 
Performance 
Environmental 
Reliability  Allocations 

Safety  Requirements  (Operational/Handling/Storage) 
Maintainability  Allocation  and  Philosophy 
Cost  Allocation 


Test  &  Evaluation 
System  Level 
Subsystem  Level 
Performance 

Environmental 
Reliability 
Maintainability 
Safety  (Systems) 
Human  Factors 
Documentation  Plans/Status 
Level 

Verification/Validation 
Product  Assurance  Ptans/Status 
Quality  Control 
Producibility 

Configuration  Management 
ILS  Plans/Status 
Support  Concept 
Responsibilities 
Manuals 

Support  Equipment 


CONCLUSIONS 


Risks 

Technical 

Cost 

Schedule 

Problem  Summary 
Problems 
Solutions/Effort 
Recommendations 


Figure  12.1.  Sample  outline  for  a  major  system  presentation  (contd). 
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12.5.2  Design  Review  Committee 


It  is  the  responsibility  of  the  design  review  committee  to 

a.  Plan  and  conduct  the  particular  design  review. 

b.  Advise  the  NOSC  program  manager  of  the  results  of  the  design  review. 

c.  Advise  the  Commander  and  technical  director  regarding  the  successful  attainment  of  a  program’s 
requirements  as  established  by  the  task  assignment  or  indicate  that  deviations  from  the  original 
requirements  are  known  and  acceptable. 

d.  Assist  the  Center  System  Safety  Branch,  Code  921,  in  the  course  of  the  review,  by  identifying 
the  critical  system  safety  risks  and  appropriately  relating  these  to  the  design  requirements  a^i 
the  safety  measures  being  taken. 

e.  Verify  for  the  technical  director  that  adequate  producibility  and  design  evaluation  have  been 
attained  prior  to  release  to  production. 

f.  Submit  recommendations  to  the  technical  director  concerning  the  full  or  limited  production 
release  to  the  cognizant  project  agency  of  a  NOSC-developed  item,  subsystem,  or  system. 

g.  Review,  prior  to  release,  any  Center  letter  to  the  cognizant  project  agency  that  recommends 
release  to  production  and  states  any  limitations  or  compromises. 

12.5.3  Organization  of  the  Design  Review  Committee 
The  committee  membership  is  as  follows: 

Chairperson *:  The  chairperson  is  the  cognizant  department  head  of  the  subject  program. 

Assistant  to  the  Chairperson :  A  person  selected  by  the  chairperson  to  assist  the  chairperson  and 
project  engineer  to  see  that  all  data  required  by  the  design  review  committee  is  acquired  prior  to 
the  meeting,  to  identify  action  items,  to  write  up  minutes  of  the  meeting,  and  to  follow  up  in 
completing  outstanding  issues  or  action  items. 

Permanent  Member *:  The  Deputy  Technical  Director,  Code  02,  assures  that  the  review  process 
is  followed  and  that  recommendations  are  complete  and  rational. 

Permanent  Recorder:  Design  Review  Office,  Code  021,  defines  design  review  requirements,  assists 
in  selection  of  review  committee  members  with  the  assistant  to  the  chairperson,  maintains  files 
of  Center  experts,  maintains  archives  of  program  reviews,  and  records  completion  of  outstanding 
action  items  as  forwarded  by  the  assistant  to  the  chairperson. 

Review  Team  Members :  The  team  members  are  selected  from  across  the  Center  by  the  chairperson 
and  Code  021  and  are  invited  to  participate  by  the  assistant  to  the  chairperson  via  channels. 
These  members  ought  to  include 

Another  technical  department  heed 

NOSC  technical  officer(s)  having  appropriate  technical  or  Fleet  background 

Independent  technical  experts  from  the  scientific  and  engineering  departments,  individually 
selected  by  the  chairperson,  with  line  management  approval,  to  meet  the  particular  needs  of 
each  design  review. 

•For  design  reviews  for  mine  systems,  these  responsibilities  may  be  delegated  to  the  appropriate  division  heads  on 
a  case-by-case  basis  with  the  approval  by  the  Technical  Director,  Code  01 . 


Ex-Officio  Advisory  Members :  These  include  additional  technical  experts,  as  required. 

See  NOSCINST  3912.1,  Design  Review  Committee,  latest  issue.  (NOSCINST  3912.1  is  updated 
annually.) 
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SECTION  13 

HARDWARE  PRODUCT  ASSURANCE 


13.1  INTRODUCTION 


13.1.1  References 

NOSC  TD  432,  Product  Assurance  Requirements  Guide  for  Naval  Ocean  Systems  Center 
Projects 
MIL-STD  470 


13.2  HARDWARE  PRODUCT  ASSURANCE  OVERVIEW 

Product  assurance  includes  those  various  engineering  and  technical  management  disciplines  that, 
when  coordinated  and  integrated  with  the  design  effort,  enhance  the  suitability  of  an  item  of  equipment 
for  production  and  Fleet  use.  Figure  13.1  illustrates  what  product  assurance  activities  take  place  during 
the  various  life-cycle  phases.  The  primary  objective  of  a  product  assurance  program  is  to  ensure  that 
products  supplied  to  the  Fleet  will  achieve  a  level  of  overall  quality  cons:stent  with  the  operational 
requirements.  In  order  to  meet  this  primary  objective,  the  hardware  product  assurance  program  is  planned 
and  structured  to  provide  the  following 

Participation  with  the  designer  in  developing  reliable,  maintainable,  and  safe  systems/equipment 

Assurance  that  the  systems/equipment  Fleet  logistic  support  requirements  have  been  fully  identified 
and  integrated  and  that  those  requirements  will  be  satisfied 

Assurance  that  systems/equipment  designs  are  producible  and  are  fully  disclosed  and  documented 
for  production 

Assurance  that  those  systems/equipment  items  that  are  fabricated  in  production  conform  to  the 
engineering  drawings  and  specifications  and  are  of  high  overall  quality 

Assurance  that  those  systems/equipment  items  that  are  introduced  into  the  Fleet  are  fully  supported 
throughout  their  life  cycle. 

The  specific  concerns  of  hardware  product  assurance,  therefore,  are 

Reliability 
Maintainability 
Availability 
System  safety 
Human  compatibility 
Quality 

of  design,  design  documentation,  and  produced  products 
Configuration  integrity 
Producibility 
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Spares  reprocurability 
Logistic  supportability 

These  concerns  have  been  ordered  in  a  set  of  engineering  and  technical  management  disciplines 
that  make  up  the  typical  hardware  product  assurance  program.  These  disciplines  are 


Reliability/maintainability  assurance 

System  safety  assurance 

Human  factors 

Quality  assurance 

Configuration  management 

Design  assurance 

Integrated  logistic  support 


These  disciplines  will  be  outlined  in  detail  in  subsections  13.3  through  13.7.  Each  of  these  subsec¬ 
tions  will  begin  with  a  definition  of  the  terms  associated  with  the  subject  and  will  include  a  review  of  the 
most  significant  policy  directive(s)  that  guides  the  discipline  activity.  The  major  task  elements  that  typically 
are  considered  when  planning  the  requirements  for  the  program  (e.g.,  the  quality  assurance  program) 
are  identified  and  described;  an  expanded  view  of  certain  program  elements  (e.g.,  environmental  stress 
screening)  is  provided.  NOSC  Technical  Document  432,  Product  Assurance  Requirements  Guide  for 
Naval  Ocean  Systems  Cent  .  Projects,  provides  additional  background  regarding  these  elements  and 
provides  recommended  conn  actual  requirements  statements  that  may  be  used  in  contract  statements 
of  work.  TD  432  also  providei  an  extensive  list  of  product  assurance  directives. 


13.3  RELIABILITY/MAINTAINABILITY  ENGINEERING 


13.3.1  Definitions 


13.3.1.1  Reliability/Maintainability  Engineerin’,.  This  is  the  continuing  analysis  and  monitoring  of 
system/equipment  design,  operation,  and  maim  nance,  throughout  its  life-cycle,  to  assure  that  it  performs 
satisfactorily  under  the  required  conditions  and  for  the  required  period  of  time. 


13.3.1.2  Reliability.  Reliability  is  the  extent  to  which  a  system/equipment  is  capable  of  performing 
its  intended  function  under  stated  conditions  without  failure.  The  measurement  of  reliability  is  expressed 
two  ways:  mean-time-between-failures  (MTBF)  and  probability  of  success  (R). 


Mean-Time-Between-Failures.  MTBF  is  the  total  functioning  life  of  a  population  of  a 
system/equipment  divided  by  the  total  number  of  failuies  within  the  population  during  a 
particular  measurement  interval.  Can  be  expressed  in  time  (hours),  cycles,  miles,  events,  or 
other  measure  of  life  applicable  to  continuous  or  intermittently  operated  systems/equipment. 


b.  Probability  of  Success.  R  is  the  probability  that  an  item  will  perform  its  intended  function 
for  a  specified  time  interval  or  mission.  It  is  expressed  as  a  decimal  value  and  is  always  with 
an  associated  confidence  level,  and  it  is  appropriate  for  use  in  connection  with  items  for  which 
operating  time  is  undefinable  (e.g.,  explosive  devices,  rockets,  and  torpedoes). 


13.3.1.3  Maintainability.  Maintainability  is  the  abili’y  of  a  failed  system/equipment,  based  on  its 
design  characteristics,  to  be  restored  to  operation.  This  is  expressed  by  mean-time-to-repair  (MTTR), 
which  is  the  total  corrective  maintenance  time  performed  on  a  population  of  a  system/equipment  divided 
by  the  total  number  of  corrective  maintenance  actions  performed.  It  is  usually  expressed  in  hours. 
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13.3.1.4  Supportability.  This  is  the  ability  to  satisfy  material  and  administrative  requirements 
associated  with  restoring  the  operation  of  a  failed  system/equipment. 

13.3.1.5  Availability.  Availability  is  the  measure  of  the  degree  to  which  a  system/equipment  is  in 
an  operable  and  committable  state  at  the  start  of  a  mission  that  is  called  for  at  an  unknown  time. 

a.  Inherent  availability  (Ai)  is  the  measure  of  a  system’s/equipment’s  performance  predicated 
on  the  inherent  design  factors  of  reliability  and  maintainability. 


MTBF 


MTBF  +  MTTR 


b.  Operational  availability  (Ao)  represents  the  expected  percentage  of  time  that  a  system/equipment 
will  be  ready  to  perform  satisfactorily  in  an  operating  environment. 


UPTIME 


UPTIME  +  DOWNTIME 


MTBF 


MTBF  +  MDT 


MDT  =  mean  downtime  (includes  both  maintainability  and  supportability  factors). 


13.3.2  Reliability  Program  Policy 


13.3.2.1  Objectives.  The  Reliability  Program  objectives  serve  to 

a.  Reaffirm  the  close  relationship  between  good,  conservative  design  and  product  reliability 

b.  Redirect  reliability  program  emphasis  towards  the  engineering  and  manufacturing  specifications. 


disciplines,  and  controls  by  which  reliable  systems/equipment  are  designed  and  produced 


13.3.2.2  Policy.  The  following  are  policy  considerations. 


a.  Reliability  is  as  important  as  functional  performance. 


b.  Defense  Systems  Acquisition  Review  Council  (DSARC)  I  (release  to  validation  phase 
development):  the  development  concept  paper  (DCP)  is  to  address  reliability  requirements 


c.  DSARC  II  (release  to  full-scale  development):  the  DCP  is  to  state  that  reliability  will  be  by 
design,  not  just  left  to  change:  the  mission  profile  will  be  defined  and  quantitative  reliability 
requirement  will  be  established. 


d.  DSARC  III  (release  to  production):  the  DCP  is  to  include  a  statement  of  reliability  achievement 
with  explanation  of  any  shortfalls  and  planned  corrective  actions. 


c.  Reliability  requirements  are  to  be  included  in  all  planning  and  procurement  documents  and 
are  to  be  a  major  factor  in  the  source  selection  and  contracting  process.  Where  appropriate, 
reliability  and  quality  incentives  should  be  included  in  contracts. 


13.3.2.3  Technical  Requirements.  The  technical  requirements  are  noted  here. 

a.  Specific  engineering  ;•  _.,  design)  and  manufacturing  disciplines  to  be  invoked.  Examples  would 


include 


MIL-STD-454,  Standard  General  Requirements  For  Electronic  Equipment 
MIL-STD-188,  Military  Communication  System  Technical  Standard 
MIL-MDBK-5C,  Metallic  Materials  and  Elements  for  Aerospace  Vehicle  Structures 
M1L-MDBK-251,  Reliability/Design  Thermal  Applications 

MIL-E-1  >400,  Electronic  Interior  Communications  and  Navigation  Equipment,  Naval  Ship 
and  Shore,  General  Specification  For 

MIL-STD-275,  Printed  Wiring  for  Electronic  Equipment 

MIL-P-55110,  Printed-Wiring  Boards 

NAVMAT  P4855-1,  Navy  Power  Supply  Reliability 

NAVMAT  P4855-2,  Design  Guidelines  for  Prevention  and  Control  of  Avionic  Corrosion 

WS-6536*,  Procedures  and  Requirements  for  Preparation  and  Soldering  of  Electrical 
Connections 

b.  Explicit  reliability  program  requirements  to  include 

Mission  profile  definition 

Allocation  of  numerical  reliability  requirements 

Parts  and  materials  program 

Conservative  parts  and  materials  derating  criteria 

Electrical,  mechanical,  and  thermal  stress  analyses 

Failure  modes,  effects,  and  criticality  analysis 

Sneak  circuit  analysis 

Worst  case  analysis  of  tolerance  buildup 

c.  Integrated  test  program  to  assess  reliability  growth  prior  to  reliability  demonstration 

Qualitication  testing  to  environmental  extremes 

Acceptance  testing  to  mission  profile  environmental  conditions,  following  burn-in.  Use 
of  environmental  stress  screening  (e.g.,  NAVMAT  P9492,  Navy  Manufacturing  Screening 
Program;  NAVSEANOTE  3900) 

d.  Reliability  tests,  where  warranted 

Reliability  development/growth  tests  where  undertainty  exists  (e.g.,  new  technology  devices, 
highly  complex  equipment  items) 

Reliability  demonstration  of  production  prototype  units 

e.  Continuous  assessment  of  reliability  in  design  and  testing 

f.  Failure  reporting,  analysis,  and  corrective  action 

Failures  recorded  in  formal  reporting  and  tracking  system 
Failures  analyzed  to  identify  cause 
Failures  corrected  to  prevent  recurrence 

•NOTE:  Eventually,  DoD-STD  2000  will  replace  WS-6536  as  the  Navy’s  soldering  standard. 
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g.  Control  over  contractor  programs  and  progress,  through 
Design  reviews  (PDR,  CDR,  DCR) 

Certification  of  test  results 
Submittal  of  reports 
Technical  audits  (e.g.,  POS). 

13.3.3  Maintainability  Program  Policy 

13.3.3.1  The  maintainability  requirements  are  defined  m  MIL-STD-47C.  The  relationships  and 
requirements 

a.  Reaffirm  the  inseparable  relationship  between  material  design  and  reliability  and  maintainability 
(R&M) 

b.  Direct  the  program  emphasis  to  the  engineering  and  manufacturing  specifications,  disciplines, 
and  controls 

c.  R&M  requirements  shall  be  considered  equal  to  functional  performance. 

d.  R&M  requirements  shall  be  addressed  as  a  major  issue  at  the  DSARC  1, 11,  and  III  reviews. 

e.  Qualitative  maintainability  requirements  (MTTR)  are  to  be  established  for  systems/equipment. 

f.  R&M  requirements  are  to  be  included  in  all  procurement  documents  and  contracts  for  new 
equipment  development.  Where  appropriate,  R&M  incentive  clauses  are  to  be  used. 

g.  R&M  programs  are  to  be  established  in  connection  with  acquisitions  and  will  include 

Maintainability  test  program 

Problems  to  be  recorded  in  a  formal  reporting  and  tracking  system 

Problems  to  be  analyzed  to  determine  necessary  corrective  action 

Corrective  action  to  be  taken  until  MTTR  requirement  satisfied 

Control  over  contractor  programs  through  design  reviews,  certification  of  test  results, 
submittal  of  reports,  and  technical  audits 

R&M  allocations  and  predictions 

Logistics  support  analysis  to  be  conducted 

h.  Realistic  qualitative  and  quantitative  (MTTR)  maintainability  design  requirements  are  to  be 
specified  that  strike  an  optimum  balance  between  logistic  support  capability,  potent’al  life- 
cycle  costs,  and  a  fully  maintainable  system. 
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i.  Maintainability  requirements  are  to  be  included  in  all  planning  and  procurement  documents. 

j.  Maintainability  program,  citing  appropriate  elements  of  MIL-STD-470,  is  to  be  established 
including 

Program  plan 
Maintainability  predictions 
Program  and  design  reviews 
Maintainability  testing 
Appropriate  data  items 
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13.3.4  Reliability  Engineering  Program  Elements 

13.3.4.1  Program  Planning,  Monitoring,  and  Control.  These  elements  include 

a.  Program  planning  —  Definition  of  the  reliability  program  (MIL-STD-785)  in  a  plan  that 
identifies  and  describes  all  program  monitoring,  control,  design,  analysis,  evaluation,  test, 
demonstration,  and  documentation  elements. 

b.  Subcontractor/Supplier  monitoring  and  control  —  Monitoring  by  the  prime  contractor  of  all 
subcontractor/supplier  reliability  program  efforts  and  ensuring  compliance  with  the  overall 
program  requirements 

c.  Program/Design  reviews  —  Review  of  the  reliability  program  progress  at  specified  points  in 
time  and  conduct  of,  as  minimum,  preliminary  and  critical  design  reviews  per  MIL-STD-1521 

d.  Failure  reporting  —  Establishment  of  a  closed-loop  failure  reporting  system  providing  for  the 
analysis  of  and  correction  of  failures 

e.  Failure  review  board  —  Review  of  significant  system/equipment  failures,  failure  trends,  and 
the  status  of  corrective  actions 

13.3.4.2  Design,  Analysis,  and  Evaluation.  These  elements  include 

a.  Reliability  modeling  —  Preparation  of  functional  flow  and  reliability  block  diagrams  of  the 
system/equipment  down  to  the  functional  module  replacement  level.  Developing  the  math  model 
and  equations  necessary  to  enable  numerical  allocations  and  predictions. 

b.  Reliability  allocation  —  Allocation  of  quantitative  system/equipment  reliability  requirements 
(mean-time-between-failures)  to  lower  assembly  units  and  to  functional  modules  based  on 
mission  and  environmental  profile  and  historical  data.  Reliability  allocation  is  a  “top-down” 
process. 

c.  Reliability/Available  trade-off  studies  —  Determination  of  the  optimum  design  approach  for 
considerations  of  both  reliability  and  availability  through  the  use  of  redundancy,  high  reliability 
components,  component  derating,  special  environmental  protection,  environmental  stress 
screening,  etc. 

d.  Parts  and  materials  selection,  application,  and  control  —  Establishment  of  m?;  mum  quality 
levels  and  application  requirements  for  electrical  (e.g.,  ER  level  “P”  or  better)  and  electronic 
components  (e.g.,  JANTX  semiconductors  or  better;  MIL-M-38510  Class  “B”  microcircuits 
or  better)  and  establishment  of  derating  criteria  using  NAVSEA  TEOOO-AB-GTP-OlOguidelines. 
Establishment  of  a  parts  identification  and  control  program  in  accordance  with  MIL-STD-965, 
procedure  1. 

e.  Reliability  prediction  —  Prediction  of  the  numerical  reliability  value  (MTBF)  of  the  functional 
modules  using  MIL-STD-756,  MIL-HDBK-217,  or  other  data;  and,  using  the  module  data 
and  available  test  data,  the  prediction  of  the  numerical  reliability  value  for  the  system/equipment. 
Reliability  prediction  is  a  “bottom-up”  process. 

f.  Stress  analysis  —  Performance  of  electrical  and  thermal  stress  analyses  of  electrical  and  electronic 
components  using  NAVSEA  TEOOO-AB-GTP-OIO  as  a  guide  and  performance  of  structural 
stress  analyses  of  critical  application  mechanical  components. 

g.  Variability  analysis  —  Performance  of  parameter  variability  (worst  case)  analyses  of  electrical 
and  electronic  components  using  NAVSEA  TEOOO-AB-GTP-OIO  as  a  guide  and  performance 


of  mechanical  tolerance  studies  of  functional  interface  features  of  mechanical  and 
electromechanical  devices. 


h.  Sneak  circuit  analysis  —  Analysis  of  critical  circuits  to  identify  latent  paths  which  could  cause 
occurrence  of  unwanted  functions  or  could  inhibit  desired  functions. 

i.  Failure  modes,  effects,  and  criticality  analysis  (FMECA)  —  Identification  of  potential  design 
weaknesses  by  determining  the  ways  an  item  may  fail,  the  cause  of  the  failure  mode,  and  effects 
and  criticality  of  the  failure  using  MIL-STD-1629. 

j.  Reliability  data  bank  —  Collection  of  reliability  data,  that  is,  equipment  operating  time,  cycle 
data,  failures,  failure  modes,  and  failure  criticality  to  assist  in  making  predictions  and  in 
determining  the  need  for  corrective  actions. 

k.  Life-cycle  effects  analysis  —  Determination  of  the  long  term  effects  of  storage,  handling, 
transportation,  maintenance,  and  repeated  testing  for  the  purpose  of  making  life-cycle  failure 
predictions  and  establishing  system/equipment  control  policies. 

13.3.4.3  Test  and  Demonstration.  These  elements  include 

a.  Environmental  stress  screening  —  Establishment  of  preconditioning  requirements  (e.g.,  “burn- 
in,”  temperature  cycling,  and  vibration)  for  components,  subassemblies,  and  major  functional 
units  in  order  to  stabilize  the  equipment’s  characteristics  and  to  stimulate  early  failures  due 
to  marginal  components  or  workmanship 

b.  Reliability  growth  testing  —  Establishment  of  a  growth  testing  program,  concentrating  on 
mission-critical  failure  mode  detection,  in  order  to  provide  early  detection  and  correction  of 
reliability  problems 

c.  Reliability  demonstration  —  Demonstration  by  formal  testing  that  the  system/equipment  mets 
its  specified  reliability  requirements,  using  M1L-STD-781  or  other  equivalent  plant 

d.  Production  testing  —  Establishment  of  a  production  reliability  test  program  to  verify  that 
system/equipment  reliability  has  not  been  degraded  by  workmanship  defects,  low  quality 
components,  or  by  other  production  related  factors 

13.3.4.4  Design  Strategies.  The  following  strategies  serve  to  satisfy  system  reliability: 

a.  Redundancy  —  Designing  one  or  more  alternate  signal  paths  into  the  system  through  addition 
of  parallel  elements 

b.  Graceful  degradation  —  Multiple  redundancy  allowing  for  automatic  switching  from  a 
malfunctioning  system  element  to  a  backup  system  element 

c.  High  reliability  design  —  Use  of  high  quality,  conservatively  derated  components.  Advantages 
over  other  strategies  include 

Reduced  initial  acquisition  costs  likely 
Lower  support  costs 
Reduced  maintenance 
Increased  availability 
Reduced  spares  requirements 
Reduced  weight  requirements 
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13.3.4.5  Component  Derating.  Component  derating  is  discussed  here: 

a.  Component  failure  rates  and  therefore  equipment  MTBF  are  directly  related  to  stress. 

b.  In  order  to  develop  a  reliable  design,  the  designer  must  identify  and  conti ol  component  stress 
levels. 

c.  Derating  is  increasing  the  ratio  (margin  of  safety)  between  part  design  limits  and  the  applied 
stresses  (i.e.,  electrical,  thermal). 

d.  Derating  provides  added  protection  from  part  variances,  decreased  part  degradation  rate,  and 
increased  expected  life. 

e.  The  use  of  properly  screened  and  qualified  components  that  are  conservatively  derated  in  their 
circuit  application  is  the  best  assurance  of  reliable  electronic  hardware. 

f.  The  case  for  using  quality  components  is  evident  from  the  following 

Components  represent  approximately  25  percent  of  the  equipment  cost  when  commercial 
grade  electronic  components  are  used. 

If  £R  level  “P”  active  and  passive  electrical  components,  MIL-S-19500  JANTX  discrete 
semiconductors,  and  MIL-M-38510  class  “B”  microcircuits  are  used,  the  parts  cost  is 
increased  by  100  to  200  percent,  and  the  equipment  cost  is  increased  by  25  to  50  percent. 
However,  the  predicted  equipment  MTBF  is  increased  14  to  20  times  over  that  of  equipment 
constructed  with  commercial  grade  components! 

13.3.4.6  Environmental  Stress  Screening  (ESS).  ESS  is  discussed  in  these  items: 

a.  Environmental  stress  screening  is  the  application  of  electrical  and  environmental  (temperature, 
vibration)  stress  to  precipitate  latent  defects  (components,  workmanship)  at  levels  of  assembly 
where  defect  correction  is  most  cost  effective. 

b.  ESS  is  not  a  test,  it  is  a  manufacturing  process. 

c.  There  is  no  relationship  between  the  environmental  levels  used  for  ESS  and  those  used  for 
qualification  testing.  ESS  levels,  typically  temperature,  often  are  higher  than  qualification  levels. 

d.  Properly  designed  ESS  will  not  damage  good  hardware,  nor  appreciably  reduce  its  useful  life. 

e.  Environmental  stress  screening  plan  guidelines 

Thermal  cycling  (applies  100  percent  to  components  and  100  percent  to  modules,  units, 
or  assemblies) 

Cycling  between  —  40°C  (-40°F)  and  90°C  (194°F)  v/ith  a  5°C/minute  minimum 
rate  of  change 

10  cycles  minimum  (20  to  30  desirable)  with  sufficient  dwell  time  (10  minutes  for 
modules)  to  ensure  stability 

During  environmental  stress  screening,  power  application  to  be  observed 

Performance  measurements  on  modules,  etc.,  to  be  made  atn  operating  temperature 
extremes  during  cycling  on  systematic  basis 

Following  cycling,  components  (i.e.,  discrete  semiconductors,  integrated  circuits)  to 
be  subjected  to 
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Electrical  tests  (i.e.,  static,  dynamic,  functional)  at  25°C  and  125°C 

Particle  impact  noise  tests  on  hybrids  and  unglassivated  semiconductors  having 
cavities 

Hermeticity  test  recommended  for  seated  devices 

Vibration  (applies  100  percent  to  modules,  units,  or  assemblies) 

Random  vibration  in  two  axes  for  10  minutes  minimum,  per  axis 

Acceleration  spectrum  of  0.04gVHz  from  20  to  2,000  Hz  with  3  dB/octave  roll  off 
from  80  to  20  Hz  and  from  350  to  2,000  Hz 

Performance  measurements  to  be  made  before  and  after  cycling. 

ESS  plan  should  be  adjusted  as  product  matures  during  full-scale  development  and 
during  production  (based  on  process  results). 

ESS  requirements,  when  fully  mature,  should  be  included  on  engineering  drawings 
for  units,  modules,  and  assemblies  that  may  be  reprocured  as  spares. 


13.3.5  Maintainability  Engineering  Program  Elements 

13.3.5.1  Program  Planning,  Monitoring,  and  Control.  These  elements  include 

a.  Program  planning  —  Definition  of  the  maintainability  program  (MIL-STD-470)  in  a  plan  that 
identifies  and  describes  all  program  monitoring,  control,  design,  analysis,  evaluation, 
demonstration,  and  documentation  elements. 

b.  Subcontractor/Supplier  monitoring  and  control  —  Monitoring  by  the  prime  contractor  of  all 
subcontractor/supplier  maintainability  program  efforts  and  ensuring  compliance  with 
maintainability  program  efforts  and  ensuring  compliance  with  the  overall  program  requirements 

c.  Program/Design  reviews  —  Revie.v  of  the  maintainability  program  progress  at  specified  points 
in  time  and  conduct  of,  as  a  minimum,  preliminary  and  critical  design  reviews  per  MIL-STD-1521 

d.  Maintainability  deficiency  reporting  —  Establishment  of  a  closed-loop  deficiency  reporting 
system  providing  for  the  analysis  of  a  correction  of  maintainability  problems 

13.3.5.2  Design,  Analysis,  and  Evaluation.  These  elements  include 

a.  Maintainability  modeling  —  Preparation,  in  conjunction  with  the  maintainability  analysis,  of 
maintainability  block  diagrams  down  to  the  major  assembly  or  module  replacement  level. 
Development  of  tne  math  model  and  equations  necessary  to  enable  numerical  allocations  and 
predictions 

b.  Maintainability  allocation  —  Allocation,  in  conjunction  with  the  maintainability  analysis,  of 
quantitative  system  equipment  maintainability  requirements  (mean-time-to-repair)  to  the  major 
assembly  or  to  the  module  replacement  level  (a  top-down  process) 

c.  Maintainability  analysis  —  Translation  of  various  system/equipment  analysis  and  Navy  operating 
constraints  data  into  detailed  quantitative  and  qualitative  maintainability  requirements  and  into 
the  detailed  maintenance  plan.  Such  analysis  data  indudes  operational  and  support  requirements; 
environmental  conditions;  overall  quantitative  maintainability  requirements;  projected 
facilities/equipment/skills  availability. 
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d.  Maintainability  design  trade-off  studies  —  Determination,  in  conjunction  with  the  maintainability 
analysis  and  whenever  design  trade-offs  are  performed  for  other  reasons,  of  the  effect  of  the 
design  approach  on  the  maintainability  aspects  of  the  system/equipment 


Maintainability  design  criteria  —  Establishment,  in  conjunction  with  the  maintainability  analysis, 
of  those  maintainability  design  criteria  that  are  to  be  considered  for  incorporation  into  the  design 
including  accessibility;  work  space;  work  clearance;  component  interchangeability  and 
standardization,  limiting  the  numbers  and  varieties  of  tools  and  support  equipment;  use  of 
maintenance-free  components;  adequate  tolerance  and  wear  factors;  failure  design;  rapid  fault 
detection  and  localization;  ease  of  adjustment  and  calibration;  limiting  personnel  numbers  and 
skills  requirements;  application  of  human  engineering  principles;  avoiding  the  potential  for 
maintenance  errors;  etc. 


f.  Maintainability  prediction  —  Prediction  of  the  maintainability  value  (MTTR)  of  the 
system/equipment  using  MIL-HDBK-472  or  other  acceptable  techniques.  Such  predictions  should 
reflect  applicable  experience  with  similar  systems/equipment  (a  bottom-up  process) 


g.  Maintainability  data  bank  —  Establishment  of  a  maintainability  data  bank,  to  be  integrated 
with  the  reliability  data  bank,  to  assist  in  making  predictions,  and  to  assist  in  evaluating  the 
demonstration  results 


Maintainability  demonstration  —  Demonstration  of  the  achievement  of  the  qualitative  and 
quantitative  (MTTR)  maintainability  requirements  for  the  system/equipment.  To  be 
accomplished  in  accordance  with  MIL-STD-471 


i.  Maintainability  program  reporting  —  Provision  for  periodic  reports  on  the  status  of  each 
maintainability  program  element 


13.4  SYSTEM  SAFETY  ENGINEERING 


13.4.1  Definitions 


13.4.1.1  System  Safety  Engineering.  This  is  the  continuing  analysis  and  monitoring  of  system/equipment 
design,  operation,  and  maintenance  to  assure  that  the  optimum  degree  of  safety  is  attained  within  the 
constraints  of  operational  effectiveness,  time,  and  cost. 


13.4.1.2  Safety.  This  is  freedom  from  conditions  that  can  cause  death,  injury,  occupational  illness, 
or  damage  to  or  loss  of  equipment  or  property. 


U  ‘  3  System  Safety.  This  is  the  application  of  engineering  and  management  techniques  to  optimize 
”ithin  the  constraints  of  operational  effectiveness,  time,  and  cost  throughout  all  life-cycle  phases. 


1  J  1  5hap.  This  is  an  unplanned  event  or  series  of  events  that  results  in  death,  injury,  occupational 
illn>  damage  to  or  loss  of  equipment  or  property. 


13.4.1.5  Hazard.  Condition  prerequisite  to  a  mishap. 

a.  Hazard  categories: 

I  (catastrophic)  —  Death  or  system  loss 

II  (critical)  —  Severe  injury,  severe  occupational  illness,  or  major  system  damage 

III  (marginal)  —  Minor  injury,  minor  occupational  illness,  or  minor  system  damage 

IV  (negligible)  —  Less  than  minor  injury,  occupational  illness,  or  system  damage 

b.  Hazard  probabilities:  1  For  individual  item 

2  For  Fleet  inventory 

A  (frequent)  —  1  Likely  to  occur  frequently 
2  Continuously  experienced 

B  (probable)  —  1  Will  occur  several  times  in  life  of  item 

2  Will  occur  frequently 

C  (occasional)  —  1  Likely  to  occur  in  life  of  item 

2  Will  occur  several  times 

D  (remote)  —  1  Unlikely,  but  possible  to  occur  in  life  of  item 

2  Unlikely,  but  can  reasonably  be  expected  to  occur 

E  (improbable)  —  1  So  unlikely,  it  can  be  assumed  it  may  not  occur 
2  Unlikely  to  occur,  but  possible 

13.4.2  System  Safety  Program  Policy 

13.4.2.1  Polic; .  System  safety  program  to  be  established  in  connection  with  all  acquisitions,  to  ensure 
Regard  for  system  safety  is  a  fundamental  element  of  the  acquisition  process. 

Personnel  will  not  be  unnecessarily  exposed  to  injury  or  health  hazards. 

Equipment  and  property  will  not  be  unnecessarily  subjected  to  damage. 

13.4.2.2  Technical  Requirements.  System  safety  program  based  on  MIL- STD-882: 

Program  plan  to  be  prepared 

Hazard  analyses  to  be  conducted  and  hazards  identified  and  categorized 
Action  taken  to  eliminate  or  control  hazards,  preferably  by  design 

Where  normal  testing  does  not  demonstrate  safe  operation,  special  safety  tests  to  be  conducted 
Document  program  efforts 

13.4.3  System  Safety  Engineering  Program  Elements 

13.4.3.1  Program  Planning  and  Control.  These  elements  include 

a.  Program  planning  —  Definition  of  the  system  safety  program  (MIL-STD-882)  in  a  plan  that 
identifies  and  describes  all  program  monitoring,  control,  analysis,  evaluation,  testing,  and 
documentation  elements 


b.  Subcontractor  monitoring  and  control  —  Monitoring  by  the  prime  contractor  of  all  subcontractor 
system  safety  program  efforts  and  ensuring  compliance  with  the  overall  program  requirements 

c.  Program/Design  reviews  —  Review  of  the  system  safety  program  progress  at  specified  points 
in  time  and  conduct  of,  as  a  minimum,  preliminary  and  critical  design  reviews  per  M1L-STD-1521 

d.  Failure  reporting  —  Establishment  of  a  closed-loop  failure  reporting  system  providing  for  the 
analysis  of  and  correction  of  safety-related  failures 

13.4.3.2  Analysis  and  Evaluation.  These  elements  include 

a.  Preliminary  hazard  analysis  —  Assessment  of  the  initial  risk  of  a  system/cquipment  or  concept 
in  order  to  identify  safety  critical  areas,  evaluate  hazards,  and  identify  the  safety  design  criteria 
to  be  used.  The  analysis  considers  the  following  for  identification  of  hazards 

Hazardous  components  (e.g.,  energy  sources,  fuels,  propellants,  explosives,  pressure  systems) 

Safety-related  interface  considerations  (e.g.,  materials  compatibility,  electromagnetic  radiation 
interference,  fire/explosion  susceptibility,  and  propagation  potential) 

Environmental  constraints,  including  the  normal  operating  environment  (e.g.,  vibration,  shock, 
temperature,  noise  or  health  hazards,  fire  electrostatic  discharge,  lightning,  X-ray, 
electromagnetic,  and  nuclear  and  laser  rad'ation) 

Operating,  test  maintenance,  and  emergency  procedures  (e.g.,  human  error  possibilities, 
environmental  effects  on  human  performance,  life-support  requirements  in  manned  systems, 
crash  survival/rescue) 

Facilities,  support  equipment,  training  (e.g.,  provisions  for  storage,  assembly,  testing  or 
training  regarding  hazardous  systems  or  where  toxic,  flammable,  explosive,  corrosive,  or 
cryogenic  materials  are  used  in  these  activities) 

Safety-related  equipment,  safeguards,  and  alternate  design  approaches  (e.g.,  interlocks, 
redundancy,  fail-safe  design  features,  personal  protective  gear,  fire  suppression  systems) 

b.  Subsystem  hazard  analysis  —  Identification  of  hazards  associated  with  component  failures  within 
a  given  subsystem.  Performed  when  detailed  design  is  completed.  Anaiysis  techniques  used  include 

Fault  hazard  analysis  —  An  inductive  method  of  analysis  involving  a  detailed  investigation 
of  subsystem  component  hazard  modes,  causes  of  liazards,  and  effects  on  the  subsystem. 
The  analysis  may  be  qualitative  or  expanded  to  a  quantitative  one. 

Fault  tree  analysis  —  A  deductive  analysis  of  all  events,  faults,  and  occurrences  that  could 
cause  or  contribute  to  the  occurrence  of  undesired  events.  The  analysis  may  be  qualitative 
or  quantitative. 

Sneak  circuit  analysis  —  Attempts  to  identify  latent  (sneak)  circuits  and  conditions  that  inhibit 
desired  functions  or  cause  undesired  functions  to  occur  without  an  accompanying  component 
failure. 

c.  System  hazard  analysis  —  Performed  on  subsystem  interfaces  to  determine  the  hazard  problem 
areas  of  the  total  system.  The  fault  hazard,  fault  tree,  and  sneak  circuit  analysis  techniques 
are  used.  The  analysis  should  consider  the  following  subsystems  relationships: 

Compliance  with  safety  criteria 

Possible  independent,  dependent,  or  simultaneous  failures 
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Safety  degradation  of  one  subsystem  under  normal  operating  conditions  of  another 

d.  Operating  and  support  hazard  analysis  —  Identification  of  potential  hazards  during  production, 
installation,  maintenance,  testing,  modification,  transportation,  storage,  operation,  training, 
or  during  other  phases  of  use  or  disposal.  Results  of  analysis  will  be  used  to  control  hazards 
and  to  determine  appropriate  safety  requirements  for  personnel,  procedures,  and  equipment, 
including 

Identifying  times  of  high  hazards  and  actions  required  to  minimize  risks 
Design  changes  necessary  to  eliminate  or  control  hazards 

Identifying  requirements  for  safety  devices  and  equipment  and  required  procedure:  for  ensuring 
their  proper  operation 

Warnings,  cautions,  and  emergency  procedures  for  operation  and  maintenance 
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Special  procedures  for  operation,  handling,  storage,  transportation,  and  modification 

e.  Safety  testing  and  demonstrations  —  Performance  of  tests  or  demonstrations  on  safety  critical 
equipment  and  procedures  to  determine  the  hazard  severity  or  to  establish  the  margin  of  safety 
of  the  design 

f.  System  safety  program  report  —  Provision  for  periodic  reports  on  the  status  of  each  system 
safety  program  element 


13.5  QUALITY  ASSURANCE 

13.5.1  Definitions 


13.5.1.1  Quality  Assurance.  This  is  the  planned  and  systematic  technical  direction  and  surveillance 
of  a  producer’s  design,  materials,  components  controls,  manufacturing  processes,  and  inspection  and 
test  practices  to  assure  the  delivery  of  systems/equipment  that  will  satisfy  the  user’s  requirements. 

13.5.1.2  Quality.  This  is  the  composite  of  all  the  attributes  or  characteristics,  inciuding  performance, 
of  a  product. 

13.5.1.3  Inherent  Quality.  This  is  the  presence  in  the  design  of  those  attributes  (e.g.,  performance, 
reliability,  survivability,  maintainability,  system  safety,  human  factors)  necessary  to  satisfy  the  user’s 
requirements  (i.e.,  design  quality). 

13.5.1.4  Manufacturing  Quality.  This  is  the  conformance  of  a  manufactured  product  to  its  required 
drawings  and  specifications. 


13.5.1.5  Achieved  Quality.  The  ability  of  a  manufactured  product  to  satisfy  the  user’s  requirements, 
i.e.  overall  product  quality. 


13,5.2  Quality  Assurance  Program  Policy 


13.5.2.1  Policy.  The  policy  is 

a.  Quality  is  to  be  a  major  factor  in  system  planning,  engineering,  and  management. 
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b.  Inherent  quality  is  established  by  ihe  design. 

c.  Assurance  of  achieved  quality  requires  a  planned  program. 

d.  Measurement  of  achieved  quality  must  be  continuous. 

13.5.2.2  Program  Requirements.  The  requirements  are  such  that 

a.  Quality  requirements  are  to  be  included  in  contracts  and  consideiaiion  given  to  quality  during 
source  selection. 

b.  Contractors’  quality  programs  are  to  be  evaluated  and  audited. 

c.  Engineering  specifications  are  to  include  quality  assurance  provisions. 

d.  Quality  requirements  are  to  be  based  on  operating  environment. 

e.  Contractor  developed  test  and  inspection  equipment  programs  are  to  be  assessed. 

f.  Quality  assurance  requirements  are  to  be  established  in  connection  with  packaging,  handling, 
shipment,  and  storage. 

g.  Quality  assurance  requirements  are  to  be  established  in  connection  with  maintenance  operations. 

h.  Quality  concepts  are  to  be  included  in  MIL-STDs,  MIL-SPECS,  and  QPLs. 

13.5.3  Quality  Assurance  Program  Elements 

13.5.3.1  Quality  Assurance  Program  Plan.  This  is  the  plan  for  assuring  the  quality  of  the  design, 
design  documentation,  and  fabricated /assembled  hardware  and  associated  computer  software. 

13.5.3.2  Hardware  Quality  Assurance  Program  Provisions.  These  elements  include 

a.  Management 

Responsibility— Identifies  the  organization  and  individual  responsible  for  program 
implementation,  management,  and  control.  Defines  responsibilities  and  authority.  Identifies 
chain-of-authority  for  reporting  purposes. 

Work  instructions 

Development  hardware.  Establishes  requirement  that  special  or  nonroutine  procedures  (e.g., 
manufacturing,  assembly,  calibration,  alignment,  testing)  be  described  by  written  work 
instructions 

Fabrication/assembly  of  Fleet  service  systems/equipment.  Establishes  requirement  tha* 
all  manufacturing  procedures  to  be  described  by  detailed,  written  work  instructions 
maintained  under  strict  configuration  control 

b.  Design  control 

Product  baseline— Provides  an  exact  definition  (listing)  of  applicable  drawings, 
specifications,  and  approved  changes  to  which  hardware  will  be  fabricated,  inspected,  and 
tested. 

Change  control— Establishes  the  system  for  documenting,  controlling,  and  accounting  for 
engineering  changes,  deviations,  and  waivers,  from  both  the  administrative  approval  and 
hardware  implementation  standpoints. 
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c.  Procurement  actions  (i.e.,  subcontracts,  purchase  orders) 

Procurement  requirements— Includes  technical  and  quality  assurance  requirements  such 
as  MIL-Q-9858  quality  program/M I L-l-45208  inspection  system;  piece  part/first  article/unit 
acceptance/lot  acceptance  inspection  and/or  test;  ESS;  change  control;  workmanship; 
soldering;  government  inspection/acceptance  authority 

Source  inspection— Expresses  ordering  activity’s  intention  to  inspect  units  of  product  at 
source 

Parts/Materials— Includes  requirement  that  purchased  components  or  fabricated  items  be 
inspected/tested  by  subcontractor  upon  receipt.  Requires  certifications  for  critical  raw 
materials 

d.  Material  control 

Identification— Requires  identification,  segregation,  and  control  of  incoming  material 
awaiting  inspection,  material  having  completed  inspection  and  found  acceptable,  and 
nonconforming  material 

Handling  control— Requires  proper  handling  of  material  during  processing 

Storage  control— Establishes  requirements  for  preservation  and  packaging  of  completed 
material 

Shipment  control — Establishes  requirements  for  pioper  preparation  for  shipment 

e.  Manufacture/ Assembly 

Process  control— Establishes  evaluations,  controls,  and  inspections  at  appropriate  points 
in  the  manufacturing  process  to  ensure  continuous  control  over  quality  of  produced  products 

Special  processes— Establishes  requirements  for  methods  and  facilities  used  in  connection 
with  soldering,  brazing,  welding,  bonding,  encapsulating,  plating,  anodizing,  heat  treating, 
nondestructive  testing,  ESS,  etc.  Requires  certification  of  personnel  performing  special 
processes. 

Workmanship — Establishes  requirements  for  general  workmanship  (MIL-STD-454, 
Requirement  9)  practices  and  any  special  product  workmanship  provisions 

f.  Acceptance  inspection  and  testing 

First  article/preproducticn  sample— Provides  confidence  that  producer  is  capable  of 
manufacturing  items  that  meet  the  full  performance  and  environmental  requirements  of 
the  drawings  and  specifications 

Unit  acceptance — Establishes  physical  inspection  and  performance  test  requirements  for 
conditional  acceptance  of  individual  units  of  lot;  100  percent  testing  of  functional  units 
and  critical  physical  features.  Large  lots  of  homogeneous,  noncritical  units  are  inspected 
on  a  statistical  sample  basis. 

Periodic  production  lot  sample— Ensures  that  randomly  selected  production  sample  items 
meet  the  full  performance  and  environmental  requirements  of  the  drawings  and 
specification*  Determines  acceptability  of  lot. 

g.  Corrective  action 

Noncomforming  material— Establishes  procedure  for  rework,  repair,  scrap,  return  to 
vendor,  or  other  disposition  (e.g.,  waiver  action)  of  discrepant  material. 


Action  to  prevent  recurrence— Establishes  technical  and/oi  administrative  action  necessary 
to  prevent  recurrence  of  the  discrepancy.  Includes  monitoring  of  effectiveness  of  corrective 
action  following  implementation. 

h.  Measuring  and  testing  equipment  control— F  sures  all  measuring  and  test  equipment  used  for 
material  acceptance  or  evaluation  purpose1'  .ibrated  before  use  and  is  subject  to  a  calibration 
recall  program. 

i.  Quality  information 

Records— Establishes  requirements  to  maintain  records  concerning  inspections/tests  of  both 
conforming  and  nonconforming  units  of  product 

Quality  cost  data— Identifies  the  cost  of  both  the  prevention  and  correction  of 
nonconforming  supplies 

13.5.4  Why  Inspect  at  the  Piece  Part  Level? 

Review  the  Burroughs  Corporation  experience  concerning  the  comparative  costs  of  locating  and 
replacing  a  defective  semiconductor  at  various  assembly  levels  in  an  item  of  equipment — J.  Zeccardi 
(Vice  Pres,  for  Quality/Service) 

Defect  Found  During  Cost  to  Locate/Replace 


Inspection  by  supplier 

S.03 

Incoming  inspection  at  Burroughs 

S.30 

Subassembly  (circuit  board)  test 

$3.00 

Assembly  test 

$30.00 

Equipment  test 

$300.00 

Field  test 

$3,000.00 

13.6  CONFIGURATION  MANAGEMENT 

13.6.1  Definitions 

13.6.1.1  Configuration  Management.  This  is  the  technical  and  administrative  direction  and  surveillance 
of  the  functional  and  physical  characteristics  of  system/equipment  hardware  or  computer  software. 

13.6.1.2  Configuration  Identification.  This  is  the  identification  and  documentation  of  the  functional 
and  physical  characteristics  of  hardware/software  with  engineering  drawings,  parts  lists,  specifications,  etc. 

13.6.13  Configuration  Control.  This  is  the  technical  analysis  and  control  of  changes  to  these  functional 
and  physical  characteristics  as  documented  by  engineering  change  proposals  (ECPs),  deviations,  and 
waivers. 

13.6.1.4  Configuration  Status  Accounting.  This  is  the  recording  of  the  approved  configuration 
identification  in  functional,  allocated,  or  product  baselines,  and  the  reporting  of  the  status  of  change 
(ECP)  processing  and  implementation. 


13.6.1.5  Configuration  Audits.  These  are  the  formal  verifications  during  Full-Scale  Development, 
through  physical  testing  (functional  configuration  audit)  and  examination  (physical  configuration  audit), 
that  the  hardware  and  its  related  configuration  identification  meet  contractual  requirements  and  program 
needs. 

13.6.1.6  Engineering  Change  Proposal  (ECP).  The  ECP  includes  both  a  proposed  engineering  change 
and  the  documentation  by  which  the  change  is  described  for  purposes  of  incorporation  into  the  affected 
drawings,  etc. 

13.6.1.7  Deviation.  This  is  a  specific  written  authorization,  granted  prior  to  the  manufacture  of  an 
item,  to  depart  from  a  particular  design  or  performance  requirement. 

13.6.1.8  Waiver.  This  is  written  authorization  to  accept  an  item  which  during  production  or  after 
having  been  submitted  for  inspection  is  found  to  depart  from  specified  requirements. 

13.6.2  Configuration  Management  Policy 

The  requirements  of  NAVMAT1NST  4130.1  are  described  by  paragraph  3,  following. 

13.6.3  Configuration  Management  Program  Elements 

13.6.3.1  Configuration  Identification.  These  elements  are  discussed  below: 

a.  Functional  baseline  (basis  for  Validation  phase) 

Type  “A”  system  specification 

Level  I  system/equipment  drawings 

b.  Allocated  baseline  (basis  for  Full-Scale  Development) 

Type  “A”  system  specification 

Type  “B”  development  specifications 
Level  II  system  drawings 
Interface  control  drawings 

c.  Product  baseline  (basis  for  production) 

Type  “C”  product,  type  “D”  process,  type  “E”  material  specifications 
Level  II/III  system/equipment  drawings 
Level  III  spare  parts  drawings 
Installation  control  drawings 

13.6.3.2  Configuration  Control  (DOD-STD-480  describes).  These  elements  include 

Engineering  change  proposals  (Class  1,  II  ECPs) 

Deviations  (critical,  major,  minor) 

Waivers  (critical,  major,  minor) 

Material  review  board  actions 

13.6.3.3  Configuration  Status  Accounting  (MIL-STD-482  describes).  These  elements  include 
Baseline  status 

ECP,  deviation,  waiver  approval  status 


ECP,  deviation,  waiver  contract  implementation  status 

“As  built”  configuration  records 

Fleet  system/equipment  configuration  records 

13.6.3.4  Configuration  Audits  (MIL-STD-1521  provides  guidelines).  These  elements  include 

Functional  configuration  audit  (FCA) 

Physical  configuration  audit  (PCA) 


13.7  INTEGRATED  LOGISTIC  SUPPORT 

13.7.1  Definition 

Integrated  logistic  support  is  a  composite  of  all  the  logistic  support  considerations  necessary  to 
assure  the  effective  and  economical  support  of  a  system/equipment  throughout  its  life  cycle;  it  is  an 
integral  part  of  the  system  acquisition  process. 

13.7.2  Integrated  Logistic  Support  Program  Policy 

The  requirements  of  NAVMATINST  4000.20,  1LS  Planning  Policy,  are  described  by  paragraph 
3,  following. 

13.7.3  Integrated  Logistic  Support  Program  Elements 

13.7.3.1  Maintenance  Plan.  This  element  includes  the  description  of  the  requirements  and  tasks  to 
be  accomplished  for  achieving,  restoring,  or  maintaining  the  operational  capability  of  a 
system/equipment.  The  basis  for  the  maintenance  plan  is  the  maintenance  concept  that  describes  the 
manner  in  which  a  system/equipment  will  be  maintained  and  supported.  The  maintenance  concept 
can  involve  the  following  maintenance  levels: 

a.  Organizational  maintenance— Planned  or  corrective/unscheduled  maintenance  by  the  operational 
unit 

b.  Intermediate  maintenance— Submarine/destroyer  tenders  (AS/AD),  repair  ships  (AR),  shore 
activities,  submarine  support  facilities 

c.  Depot  maintenance— Organic  (Navy/DoD)  or  commercial  designated  overhaul  points  (DOP) 

d.  Di.ect  Fleet  support— Direct  technical  assistance  to  organization  and  intermediate  levels  (e.g., 
mobile  technical  units) 

13.7.3.2  Manpower  and  Personnel.  This  includes  requirements  for  the  numbers  (officers  and  enlisted 
personnel)  and  skills  (classifications)  of  personnel  to  operate  and  maintain  the  system/equipment. 

13.7.3.3  Supply  Support.  This  addresses  the  requirements,  including  the  initial  operating  requirements, 
for  provisioning  material  needed  at  all  maintenance  levels  including  spare  and  repair  parts  and 
consumables.  Supply  support  considerations  include  expected  frequency  of  repair  and  need  for  early 
supply  support,  phased  provisioning  or  prescreening,  anticipated  contractor  depot  support,  and  repairable 
material  program.  Supply  support  plan  decisions  are  reflected  in  various  items  of  provisioning  technical 
documentation  (e.g.,  provisioning  parts  list,  common  and  bulk  items  list,  interim  support  items  list, 
long  lead  time  items  list,  and  tools  and  test  equipment  list). 


13.7.3.4  Support  and  Test  Equipment  (S&TE).  This  includes  requirements  for  special  and  standard 
test  equipment,  special  and  standard  tods,  fixtures,  etc.  and  requirements  for  maintenance  and  calibration 
of  these  devices. 

13.7.3.5  Training  and  Ti  lining  Devices.  This  addresses  requirements  for  training  of  personnel, 
including  both  initial  and  follow-on/refresher  training,  as  well  as  requirements  for  training  materials 
(e.g.,  instructor /lesson  training  course  guides,  student’s  training  course  guides)  and  for  training  devices 
or  equipment  including  their  development,  fabrication,  maintenance,  and  other  support. 

13.7.3.6  Technical  Data.  This  includes  requirements  for  technical  manuals  or  other  documents  (e.g., 
maintenance  requirements  cards)  for  the  organizational,  intermediate,  and  depot  maintenance  levels, 
including  the  detailed  format  and  technical  contents;  the  validation  and  verification  and  the  life-cycle 
maintenance;  engineering  drawings  and  product  specifications  acquisition  and  maintenance  for  use  in 
procurement  of  systems/equipment  and  their  spare  parts  and  for  depot  repair  operations. 

13.7.3.7  Computer  Resources  Support.  This  includes  requirements  for  all  computer  equipment  and 
computer  software  and  the  requirements  for  their  support. 

13.7.3.8  Packaging,  Handling,  Storage,  and  Transportation  (PHST).  This  includes  requirements 
for  preservation,  packaging,  packing,  and  marking,  including  special  containers  to  prevent  damage 
during  shipment  and  storage;  jigs,  fixtures,  or  other  equipment  needed  for  movement  during  shipment; 
space  and  environment  for  storage,  including  storage  related  maintenance;  primary  and  alternate  modes 
of  transportation. 

13.7.3.9  Facilities.  This  addresses  requirements  for  the  construction  or  modification  of  new  or  existing 
facilities  of  all  types,  including  assembly  maintenance,  and  for  storage  facilities  both  afloat  and  ashore. 
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SECTION  14 

SOFTWARE  PRODUCT  ASSURANCE 


14.1  INTRODUCTION 

14.1.1  References 

See  subsection  14.2.2.1. 

14.1.2  Summary 

Software  development  begins  with  the  identification  of  the  need  for  a  computer  software  product 
and  ends  with  the  successful  operation  of  the  developed  software  in  the  user’s  environment.  This  section 
describes  the  Department  of  Defense’s  structured  approach  to  the  organization  of  the  activities  required 
throughout  the  development  cycle. 

The  simplest  analysis  of  the  software  development  process  yields  a  three-phase  approach  (Figure  14.1). 
These  three  steps,  while  common  to  the  development  and  use  of  all  computer  programs,  are  independent 
of  the  size,  complexity,  or  application.  In  fact,  these  steps  may  be  all  that  are  required  if  the  program 
is  very  small  and  used  exclusively  by  the  implementer.  However,  a  software  development  plan  (SDP) 
designed  around  these  three  steps  cannot  succeed  for  larger  software  development  projects. 

The  major  problem  with  this  approach  is  the  lack  of  intermediate,  measurable  milestones  to  provide 
checkpoints  for  the  development  process.  To  introduce  meaningful  checkpoints  would  produce  the 
software  development  methodology  shown  in  Figure  14.2.  Each  phase  or  step  ends  with  a  measurable 
milestone  (e.g.,  complete  software  specification,  preliminary  design,  detailed  design).  Furthermore, 
each  phase  of  the  process  will  require  iterations  with  adjacent  phases  and  to  a  lesser  degree  iteration 
with  phases  further  back  in  the  process.  This  provides  a  fallback  position  allowing  effective  use  of 
earlier  work  in  the  development  process.  The  definition,  refinement,  and  formalization  of  products 
and  the  monitoring  techniques  for  these  processes  make  up  the  project  activities.  This  software 
development  process  is  divided  into  six  phases: 

a.  System  requirements  analysis 

b.  Detailed  design 

c.  Coding 

d.  Unit  testing 

e.  Integration  testing 

f.  Computer  software  configuration  item  (CSC1)  certification  testing.  Tasks  performed  within 
each  phase  of  the  software  development  process  produce  documents  required  to  control  and 
monitor  the  software  design  and  to  produce  coded  programs,  verified  and  delivered  to  the  user. 
Technical  reviews  are  used  to  formalize  the  development  control  process  and  to  validate  budget 
and  schedule  reports. 
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Figure  14.1.  The  three-phase  software  development  process. 


14.2  PROJECT  MANAGEMENT 

Early  in  the  project  definition  phase  for  internal  projects  or  during  preproposal  activities  for 
competitive  procurements,  the  selected  project  manager  needs  to  take  the  lead  in  establishing  the  project 
starting  point.  This  task  includes  identifying  high-risk  areas  and  establishing  budgets,  schedules,  staffing 
plan,  task  allocations,  support  organizational  requirements,  project  interface  techniques,  subcontractor 
requirements,  and  the  project/customer  interface  approach.  The  planning  for  these  activities  is  required 
to  be  included  in  the  project  management  plan. 

The  project  management  plan  (PMP)  defines  the  project  starting  point.  This  plan  also  provides 
the  definitions  of  what  will  be  done,  how,  by  whom,  on  what  schedule,  and  which  development  and 
management  tools  and  techniques  will  be  used.  The  project  manager  controls  the  software  development 
activities  on  the  basis  of  plans  prepared  at  the  start  of  the  project  and  updated  as  required.  There  are 
several  management  tools  that  can  assist  the  project  managet  in  successfully  completing  the  software 
development  project,  e.g.,  schedules,  WBS,  documentation,  configuration  control,  standards  and 
conventions,  and  subconti acting.  The  PMP  should  include  sections  for  each  of  these  areas.  The  PMP 
should  also  describe  the  intended  use  of  each  of  these  management  tools  to  support  the  project  manager’s 
task  of  planning,  progress  analysis,  problem  resolution,  and  project  coordination. 

14.2.1  Scope  (DoD-STD-2 167) 

14.2.1.1  Purpose.  DoD-STD-2167  establishes  requirements  to  be  applied  during  the  dev  elopment  and 
acquisition  of  mission  critical  computer  systems  (MCCS). 

14.2.1.2  Application.  DoD-STD-2167  applies  to 

a.  Deliverable  software  designated  as  a  computer  software  configuration  item  (CSC1) 

b.  Development  as  part  of  a  hardware  configuration  item  (HWCI) 

c.  Nondeliverable  development  and  test  software 

d.  Deliverable  unmodified  commercial  and  reusable  software 

e.  Modified  commercial,  GFI,  and  reusable  software 

14.2.1.3  Software  Development  by  Government  Agencies.  The  provisions  of  MII.-STD-2167  apply 
to  government  agencies  acting  as  software  developers.  In  this  case,  the  term  “contractor”  refers  to 
the  government  agency  that  is  developing  the  software  Any  contractor  of  that  government  agency 
is  classified  as  a  subcontractor. 

14.2.1.4  Tailoring  MIL-STD-2167.  The  contracting  agency  will  tailor  DoD-STD-2167  to  require  only 
what  is  needed  for  each  individual  acquisition.  Guidelines  for  applying  this  standard  are  provided  in 
Appendix  0  of  DoD-STD-2167. 


14.2.2  Government  Documents 


14.2.2.1  Specifications,  Standards,  and  Handbooks.  Unless  otherwise  specified,  the  following 
specifications,  standards,  and  handbooks  of  the  issue  listed  in  thr*t  issue  of  the  Department  of  Defense 
Index  of  Specifications  and  Standards  (DoDISS)  specified  in  the  solicitation  form  a  part  of  DoD- 
STD-2167  to  the  extent  specified  herein. 

STANDARDS,  MILITARY 

D0D-STD-48O  Configuration  Control— Engineering  Changes,  Deviations,  and  Waivers 

MIL-STD-481  Configuration  Control— Engineering  Changes,  Deviations  and  Waivers  (Short 
Form) 

MIL-STD-433  Configuration  Management  Practices  for  Systems,  Equipment,  Munitions,  and 
Computer  Software 

MIL-STD-490  Specification  Practices 

MIL-STD-881  Work  Breakdown  Structures  for  Defense  Material  Items 

MIL-STD-1521  Technical  Reviews  and  Audits  for  Systems,  Equipments,  and  Computer  Software 

MIL-STD-1535  Supplier  Quality  Assurance  Program  Requirements 

14.2.2.2  Other  Government  Documents,  Drawings,  and  Publications.  None.  (Copies  of  specifications, 
standards,  handbooks,  drawings,  and  publications  required  by  contractors  in  connection  with  specific 
acquisition  functions  should  be  obtained  from  the  contracting  agency  or  as  directed  by  the  contracting 
officer.) 

14.2.2.3  Other  Publications.  None. 

14.2.2.4  Order  of  Precedence.  In  the  event  of  a  conflict  between  the  text  of  this  standard  and  the 
references  cited  herein,  the  text  of  this  standard  shall  take  precedence. 

14.3  DEFINITIONS 

14.3.1  Allocated  Baseline 

The  initial  approved  allocated  configuration  identification  as  specified  m  DoD-STD-480. 

14.3.2  Authentication 

The  procedure  (essentially  approval)  used  by  the  government  in  verifying  that  specification  content 
is  acceptable.  Authentication  does  not  imply  acceptance  or  responsibility  by  the  government  for  the 
specified  item  to  perform  successfully. 

14.3.3  Baseline 

A  configuration  identification  document  or  a  set  of  such  documents  (regardless  of  media)  formally 
designated  and  fixed  at  a  specific  time  during  a  configuration  item’s  life  cycle.  Baselines,  plus  approved 
changes  from  those  baselines,  constitute  the  current  configuration  identification. 
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14.3.4  Certification 


A  process,  which  may  be  incremental,  by  which  a  contractor  provides  evidence  to  the  contracting 
agency  that  a  product  meets  contractual  or  otherwise  specified  requirements. 

14.3.5  Computer  Data  Definition 

A  statement  of  the  characteristics  of  basic  elements  of  information  operated  upon  by  hardware 
in  responding  to  computer  instructions.  These  characteristics  may  include,  but  are  not  limited  to,  type, 
range,  structure,  and  value. 

14.3.6  Computer  Software  (or  Software) 

A  combination  of  associated  computer  instructions  and  computer  data  definitions  required  to  enable 
the  computer  hardware  to  perform  computational  or  control  functions. 

14.3.7  Computer  Software  Components  (CSC) 

A  functional  or  logically  distinct  part  of  a  computer  software  configuration  item.  Computer  software 
components  may  be  top-level  or  lower-leve!. 

14.3.8  Computer  Software  Configuration  Item  (CSCI) 

See  Configura  ion  hem  (14.3.12). 

14.3.9  Computer  Software  Documentation 

Technical  data  or  information,  including  computer  listings  and  printouts,  which  document  the 
requirements,  design,  or  details  of  compute:  software;  explain  the  capabilities  and  limitations  of  the 
software;  or  provide  operating  instructions  for  using  or  supporting  computer  softwa-e  during  the 
software’s  operational  life. 

14.3.10  Computer  Software  Quality  (or  Software  Quality) 

The  degree  to  which  the  attributes  of  the  software  enable  it  to  perform  its  specified  end  item  use. 

14.3.11  Configuration  Identification 

The  current  approved  or  conditionally  approved  technical  documentation  for  a  configuration  item 
as  set  forth  in  specifications,  drawings,  and  associated  lists,  and  Documents  referenced  therein. 

14.3.12  Configuration  Item 

Hardware  or  software,  or  an  aggregation  of  both,  which  is  designated  by  the  contracting  agency 
for  configuration  management. 


14.3.13  Developmental  Configuration 


The  contractor’s  software  and  associated  technical  documentation  that  define  the  evolving 
configuration  of  CSCI  during  development.  It  is  under  the  development  contractor’s  configuration 
control  and  describes  the  software  configuration  of  the  design,  coding,  and  testing  effort.  Any  item 
in  the  development  configuration  may  be  stored  on  electronic  media. 

14.3.14  Firmware 

The  combination  of  a  hardware  device  and  computer  instructions  or  computer  data  that  reside 
as  read-only  software  on  the  hardware  device.  The  software  cannot  be  readily  modified  under  program 
control  The  definition  also  applies  to  read-only  digital  data  that  may  be  used  by  electronic  devices 
other  than  digital  computers. 

14.3.15  Format  Test 

A  test  conducted  in  accordance  with  test  plans  and  procedures  approved  by  the  contracting  agency 
and  witnessed  by  an  authorized  contracting  agency  representative  to  show  that  the  software  satisfies 
a  specified  requirement. 

14.3.16  Functional  Baseline 

^he  initial  approved  functional  configuration  identification  as  specified  in  DoD-STD-480. 

14.3.17  Hardware  Configuration  Item  (HWCI) 

See  Configuration  Item  (14.3.12). 

14.3.18  Informal  Test 

Any  test  which  does  not  meet  all  the  requirements  of  a  formal  test. 

14.3.19  Modular 

Pertaining  to  software  that  is  organized  into  limited  aggregates  of  data  and  contiguous  codes  that 
perform  identifiable  functions. 

14.3.20  Product  Baseline 

The  initial  approved  product  configuration  identification  as  specified  in  DoD-STD-480. 

14.3.21  Software  Development  Library  (SDL) 

A  controlled  collection  of  software,  documentaiion,  and  associated  tools  and  procedures  used  to 
facilitate  the  orderly  development  and  subsequent  support  of  software.  A  software  development  library 
provides  storage  of  and  controlled  access  »o  software  and  documentation  in  both  human-readable  and 
machine-readable  form.  The  library  may  also  contair  management  data  pertinent  to  the  software 
development  project. 


14.3.22  Top-Down 


Pertaining  to  an  approach  that  starts  with  the  highest  level  of  a  hierarchy  and  proceeds  through 
progressively  lower  levels.  For  example,  top-down  design,  top-down  coding,  top-down  testing. 

14.3.23  Unit 

The  smallest  logical  entity  specified  in  the  detailed  design  wh’ch  completely  describes  a  single  function 
in  sufficient  detail  to  allow  implementing  code  to  be  produced  and  tested  independently  of  other  units. 
Units  are  the  actual  physical  entities  implemented  in  code. 


14.4  GENERAL  REQUIREMENTS 

The  contractor/developer  shall  implement  a  software  development  cycle  that  includes  the  following 
six  phases: 

a.  Software  requirements  analysis 

b.  Preliminary  design 

c.  Detailed  design 

d.  Coding  and  unit  testing 

e.  CSC  integration 

f.  CSCI  testing 

14.4.1  Computer  Software  Organization 

Computer  software  developed  in  accordance  with  DoD-STD-1679  shall  be  organized  as  one  or 
more  CSCIs  or  other  types  of  software.  Each  CSCI  is  part  oi  a  system,  systen.  segment,  or  prime  item 
and  shall  consist  of  one  or  more  top-level  computer  software  components  (TLCSCs).  Each  TLCSC 
shall  consist  of  lower  level  computer  software  components  (LLCSCs)  or  units.  TLCSCs  and  LLCSCs 
are  logical  groupings.  Units  are  the  smallest  logical  entities,  and  the  actual  physical  entities  implemented 
in  code.  The  static  structure  of  CSCIs,  TLCSCs,  LLCSCs,  and  units  shall  form  a  hierarchical  structure 
and  shall  uniquely  identify  all  CSCIs,  TLCSCs,  LLCSCs,  and  units.  The  partitioning  of  the  components 
and  units  may  be  based  on  functional  requirements,  data  flow  requirements,  or  other  design 
considerations. 

14.4.2  Software  Quality 

The  contractor/developer  shall  plan  and  implement  the  software  development  project  with  the 
objective  of  building  in  quality.  Tc  achieve  this  quality  the  contractor  shall 

a.  Establish  and  maintain  a  complete  set  of  requirements 

b.  Establish  and  implement  a  complete  process  for  developing  the  software  (SDP,  SCMP,  and 
SSPM) 

c.  Establish  and  maintain  a  software  quality  evaluation  process  (SDEP) 
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14.4.3  Subcontractor  Control 

When  NOSC  is  the  software  development  agency,  NOSC  plays  the  role  of  a  prime  contractor. 
A  prime  contractor  shall  ensure  that  all  subcontractors  developing  software  and  documentation  comply 
with  subcontracting  requirements. 


14.4.4  Nondeliverable  Software,  Firmware,  and  Hardware 

The  contractor/developer  shall  describe  in  the  SDP  the  controls  to  be  imposed  on  all  nondeliverable 
software,  firmware,  and  hardware  used  in  the  development  and  acquisition  of  deliverable  software. 
As  a  minimum,  the  contractor/developer  shall  describe  the  provisions  for 

a.  Modifications 

b.  Documentation 

c.  Configuration  management 

d.  Design  and  coding  standards 

e.  Testing 

f.  Quality  evaluation 

g.  Certification 

14.4.5  Firmware 


£  The  application  of  DoD-STD-2167  to  firmware  depends  on  whether  the  firmware  is  designated 

V  as  a  CSCI  or  as  part  of  a  HWCI.  If  the  software  to  be  implemented  in  firmware  is  considered  part 

$  of  the  HWCI,  the  contractor/developer  shall  identify  the  applicable  requirements  in  the  SDP.  These 

i  requirements  are  subject  to  the  contracting  agency  approval/disapproval. 


14.5  DEVELOPMENT  PROCESS 


14.5.1  Concept  Exploration  Phase 

145.1.1  Purpose.  The  objectives  of  the  concept  exploration  phase  are  to  explore  system  concepts 
and  to  determine  the  feasibility  of  using  computer  resources  to  satisfy  operational  needs.  This  phase 
includes 

a.  Defining  system  level  requirements 

b.  Analyzing  development  concepts 

a  Analyzing  alternative  allocation  of  system  requirements 

d.  Defining  intersystem  interfaces 

e.  Developing  initial  planning  documents 
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14.5.1.2  Products.  The  following  engineering  products  are  developed  during  this  phase: 

a.  Preliminary  system/segment  specification  (SSS)  DI-MCCR-80008 

b.  Preliminary  test  and  evaluation  master  plan  (TEMP) 

c.  Preliminary  computer  resource  life  cycle  management  plan 
(CRLCMP) 

14.5.1.3  System  Requirements  Review  (SRR)  and  Baseline.  A  system  requirements  review  will  be  held 
to  evaluate  the  adequacy  of  system  requirements  contained  in  the  draft  SSS  in  meeting  the  stated 
operational  needs. 

The  authenticated  SSS  establishes  the  functional  baseline.  However,  the  SSS  is  normally  authenticated 
at  the  system  design  review. 

14.5.1.4  Activities,  Plans,  and  Controls.  After  a  need  for  a  new  mission  capability  has  been  identified 
and  validated,  a  program  will  be  initiated  to  explore  alternative  system  concepts.  Concept  exploration 
may  be  directed  toward  refining  proposed  solutions  or  developing  new  concepts. 

Exploratory  activities  may  include 

a.  System  engineering  studies 

b.  Feasibility  studies 

c.  Trade-off  studies 

d.  Risk  assessments 

e.  Requirements  definition 

f.  Computer  resource  use  studies 

g.  Operational  concept  analysis 

h.  Support  concept  studies 

i.  Test  and  evaluation  planning 

j.  Initial  software  quality  planning 

k.  Independent  verification  and  validation  planning 

14.5.1.5  Management  Documents.  The  following  management  documents  are  normally  developed 
during  this  phase: 

a.  Initial  software  quality  evaluation  plan  (SQEP)  DI-MCCR 

b.  Initial  computer  resource  life  cycle  management  plan  (CRLCM) 

14.5.1.6  Quality  Factors.  Software  quality  planning  will  begin  during  this  phase.  Quality  factors  will 
be  defined  and  the  overall  software  evaluation  process  for  the  software  development  cycle  will  be 
established  to  the  maximum  extent  possible.  The  planning  will  include  a  determination  of  the  level  of 
IV&V  (independent  validation  and  verification  to  be  used  during  subsequer.'  phases.  Achieving  software 
quality  requires  that  the  quality  be  built  in  from  the  start  and  that  it  be  evaluated  throughout  the  software 
development  cycle. 
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14.5.1.7  Qualification  Requirements.  See  Demonstration  and  Validation  Phase  (14.5.2). 


14.5.2  Demonstration  and  Validation  Phase 

14.5.2.1  Purpose.  The  objectives  of  the  demonstration  and  validation  phase  are  to  validate  system 
requirements  and  to  demonstrate  that  the  system,  including  its  computer  resources,  is  suitable  for 
engineering  development.  During  this  phase,  system  requirements  are  allocated  and  computer  resource 
life  cycle  planning  is  completed. 

14.5.2.2  Products.  The  following  engineering  products  will  be  developed  in  final  or  preliminary  form 
during  this  phase: 

a.  System/segment  specification  (SSS)  (finalize)  Dl-MCCR-80008 

b.  Computer  resource  life-cycle  management  plan  (CRLCMP)  (finalize) 

c.  Test  and  evaluation  master  plan  (TEMP)  (finalize) 

d.  Preliminary  operational  concept  document  (OCDP)  DI-MCCR-80023 

e.  Preliminary  software  requirements  specification  (SRS)  DI-MCCR-80025 

f.  Preliminary  interface  requirements  specifications  (IRS)  DI-MCCR-80026 

14.5.2.3  System  Design  Review  (SDR)  and  Baseline.  The  purpose  of  the  SDR  is  to  formally  assess 
the  allocated  system  requirements  before  proceeding  with  the  software  requirements  analysis  and  the 
preliminary  design  of  the  software  and  hardware.  The  SDR  will  evaluate  the  optimization,  traceability, 
completeness,  and  risk  associated  with  the  allocated  requirements.  A  successful  SDR  will  be  predicted 
on  the  determination  that  the  SSS  is  an  adequate  basis  for  developing  hardware  and  software 
configuration  items.  The  functional  baseline  defines  the  system  as  it  enters  the  full-scale  development 
(FSD)  phase.  If  the  SSS  has  not  previously  been  authenticated  it  will  be  authenticated  following  the 
successful  completion  of  the  SDR  and  will  establish  the  functional  baseline.  The  functional  baseline, 
established  by  the  authenticated  SSS,  will  be  under  government  configuration  control. 

14.5.2.4  Activities,  Plans,  and  Controls.  System  requirements  will  be  completed  and  defined  for 
each  HWCI  and  CSCI.  The  contracting  agency  will  plan  for 

a.  System  engineering  studies 

b.  Feasibility  studies 

c.  Trade-off  and  optimizatio.i  studies 

d.  Risk  management 

e.  Definition  of  the  system  requirements 

f.  Validation  of  requirements 

g.  Software  support 

h.  Interface  definition 

i.  Prototype  computer  resources 


The  continuous  activities  are 


a.  Computer  resource  iife  management  planning 

b.  Computer  resource  working  group  (CRWG)  support 

c.  Configuration  management 

d.  Software  quality  evaluation 

e.  Test  and  evaluation  planning 

f.  Independent  verification  and  validation  support 

g.  Operational  concepts  refinement 

14.5.2.5  Management  Documents.  The  contractor/developer  shall  develop  and/or  update  and 
establish  internal  control  over 

a.  Software  development  plan  (SDP)  Dl-MCCR-80030 

b.  Software  configuration  management  plan  (SCMP)  Dl-MCCR-80009 

c.  Software  quality  evaluation  plan  (SQEP)  DI-MCCR-80010 

d.  Software  standards  and  procedures  (SSPM)  manual  DI-MCCR-8001 1 

14.5.2.6  Quality  Factors.  The  quality  factors  pertaining  to  system  quality  will  be  specified.  Typical 
n..ality  factors  are 

a.  Reliability 

b.  Modificability 

c.  Maintainability 

d.  Flexibility 

e.  Availability 

f.  Portability 

g.  Efficiency 

14.5.2.7  Qualification  Requirements.  System  level  qualification  requirements  shall  be  specified  during 
this  phase.  Typically,  the  following  information  is  required: 

a.  Qualification  methods 

b.  Philosophy  of  testing 

c.  Location  of  testing 

d.  Responsibility  for  tests 

e.  Test  levels 

f.  Formal  test 

g.  Formal  test  constraints 
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14.5.3  Software  Requirements  Phase 


14.5.3.1  Purpose.  The  purpose  of  the  software  requirements  is  to  define  and  document  the  functional, 
performance,  interface,  and  qualification  requirements  for  each  computer  software  configuration  item 
(CSCI).  The  requirements  will  be  derived  from  the  system  requirements  as  defined  in  the  system/segment 
specification  (SSS). 


14.5.3.2  Products.  The  engineering  products  produced  during  this  phase  are 


a.  Software  requirements  specification  (SRS) 

b.  Interface  requirements  specification  (IRS) 

c.  Completed  operational  concept  document  (OCD) 


DI-MCCR-80025 

DI-MCCR-80026 

Dl-MCCR-80023 


14.5.3.3  Formal  Design  Reviews  and  Baseline.  At  the  conclusion  of  the  software  requirements  phase, 
a  software  specification  review  (SSR)  is  held.  Upon  completion  of  the  SSR  and  when  authenticated 
by  the  contracting  agency,  the  SRS  and  IRSs  will  establish  the  allocated  baseline  for  each  CSCI.  See 
MIL-STD-483,  1521B,  and  490  regarding  the  baseline  process. 


14.5.3.4  Activities,  Plans,  and  Controls.  The  ccntractor’s/developer’s  plans,  controls,  and  activities 
for  software  development  shall  include 


a.  Resources  and  organisation 

b.  Schedules  and  milestones 

c.  Standards  and  procedures 

d.  Configuration  management 

e.  Quality  evaluation 

f.  Data  rights 

g.  Nondeliverable  software 

h.  Software  that  is  part  of  a  HWCI 

i.  Interface  management  between  contractors 


14.5.3.5  Management  Documents.  The  contractor/developer  shall  develop  or  finalize  and  establish 
internal  control  over 


a.  Software  development  plan  (SDP) 

b.  Software  standards  and  procedures  manu,.'.  (SSPM) 

c.  Software  configuration  management  plan  (SCMP) 

d.  Software  quality  evaluation  plan  (SDEP) 


DI-MCCR-80030 
DI-MCCR-8001 1 
DI  MCCR-80009 
DI-MCCR-80010 


14.5.3.0  Quality  Factors.  The  quality  factor  requirements  applicable  to  each  CSCI  shall  be  specified, 
defined,  and  included  in  the  software  requirements  specification.  A  candidate  set  of  quality  factors 
fellows: 


a.  Correctness 

b.  Reliability 
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c.  Efficiency 

d.  Integrity 

e.  Usability 

f.  Maintainability 

g.  Testability 

h.  Portability 

i.  Reusability 

j.  Interoperability 

In  addition  to  establishing  quality  factors,  a  traceability  table  mapping  software  requirements  to 
corresponding  system  requiremenis  shall  be  developed  and  maintained  current  and  correct. 

14.5.3.7  CSCI  Qualification/Quality  Evaluation  Requirements.  During  this  phase,  the 
contractor/developer  shall  establish  the  qualification  methods  which  will  be  used  to  show  that  the 
requirements  of  the  CSCI  have  been  satisfied.  Typical  qualification  methods  are 

a.  Demonstration 

b.  Testing 

c.  Analysis 

d.  Inspection 

The  contractor/developer  is  required  to  monitor  the  software  development  effort  for  consistency 
with  the  SDP,  SCCMP,  SCMP,  and  SQEP  and  to  notify  the  contracting  agency  of  proposed  changes 
to  these  documents.  The  proposed  changes  are  subject  to  disapproval  by  the  contracting  agency.  In 
addition,  the  contractor/developer  shall  notify  the  contracting  agency  of  any  actions  or  procedures 
that  deviate  from  the  SDP,  SSPM,  SCMP,  or  SQEP. 

14.5.4  Preliminary  Design  Phase 

14.5.4.1  Purpose.  The  purpose  of  the  preliminary  design  phase  is  tc  develop  a  top-level  design  for 
each  CSCI  which  completely  reflects  the  requirements  contained  in  the  SRS  and  the  IRSs.  In  ad"1  lion, 
the  contractor  should  develop  lower-level  design  for  critical/high  risk  elements  of  the  CSCI. 

14.5.4.2  Products.  The  engineering  products  produced  during  this  phase  are 

a.  Software  top-level  design  specification  (STLDS)  DI-MCCR-80012 

b.  Software  test  plan  (STP)  DI-MCCR-80014 

c.  Preliminary  computer  resources  integrated  support  document 

(CRISD)  DI-MC^R-80024 

d.  Preliminary  computer  systems  operators  manual  (CSOM)  DI-MCCR-80018 

e.  Preliminary  software  users  manual  (SUM)  DI-MCCR-80019 

f.  Preliminary  computer  systems  diagnostics  manual  DI-MCCR-80020 


14.5.4.3  Formal  Design  Review  and  Baseline.  The  purpose  of  the  preliminary  design  review  (PDR) 
is  to  review  the  top-levd  design,  the  test  plans,  and  the  preliminary  operation  and  support  documents 
with  the  contracting  agency  and  to  demonstrate  that 

a.  The  top-level  design  satisfies  the  software  requirement  allocated  from  the  software  requirements 
specifications  and  the  system  requirements. 

b.  The  test  plan  establishes  adequate  test  criteria  to  qualify  each  CSC1  and  addresses  all  specified 
requirements. 

c.  The  preliminary  versions  of  the  CSOM,  SUM,  CSDM,  and  CRISD,  will,  in  final  form, 
adequately  address  the  operation  and  support  of  the  computer  system. 

d.  For  critical  lower-level  elements  being  designed  concurrently  with  the  top-level  elements,  the 
preliminary  versions  of  the  SDDD,  IDDs,  and  DBDDs  should  be  reviewed. 

Documents  produced  during  the  preliminary  design  phase  are  entered  into  the  development 
configuration  and  controlled  by  the  contractor/developer. 

14.5.4.4  Activities,  Plans,  and  Controls.  The  contractor/developer  shall  monitor  the  development 
effort  for  consistency  and  compliance  with  the 

a.  Software  development  plan 

b.  Software  configuration  management  plan 

c.  Software  quality  evaluation  plan 

d.  Software  standards  and  procedures  manual 

During  this  phase,  the  contractor/devcloper  shall  establish  the  top-level  design  to  each  CSCI  by 
allocating  requirements  from  the  SRS  and  IRSs  to  the  'op-level  components  of  each  CSCI.  In  defining 
each  top-level  component,  the  contractor/developer,  as  a  minimum,  shall  identify 

a.  Top-level  components  place  in  the  CSCI  structure 

b.  Functions  allocated  to  the  top-level  component 

c.  Memory  size  and  processing  time 

d.  Functional  control  and  data  flow 

e.  Known  interrupts  and  special  control  features 

f.  Global  data  shared  with  other  top-level  components 

g.  Inputs,  local  data,  interrupts,  timing  and  sequencing,  processing,  and  outputs  of  the  top-level 
component 

Test  plans  for  both  informal  and  formal  test  shall  be  developed. 

Informal  testing  includes  unit  testing  and  integration  testing.  Information  test  documentation  does 
not  require  government  approval.  However,  it  shall  be  made  available  for  government  review. 

For  unit  testing,  the  contractor/developer  shall  identify 

a.  Overall  test  requirements 

b.  Test  responsibilities 

v.  Schedule  information 
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Formal  testing  consists  of  testing  fully  implemented  CSCI(s)  to  demonstrate  that  each  CSCI  satisfies 
its  specified  requirements.  Formal  testing  also  applies  to  top-level  components,  low-level  components, 
and  unit  testing  when  compliance  with  specified  requirements  cannot  be  demonstrated  at  the  CSCI 
level.  Formal  test  documentation  requires  government  approval. 

For  formal  test,  the  contractor/developer  shall,  as  a  minimum,  identify 

a.  Test  requirements 

b.  Test  organization,  responsibilities,  and  schedule 

c.  Classes/types  of  forma!  tests 

d.  Data  recording,  reduction,  and  analysis 

e.  Purpose  of  each  formal  test 

14.5.4.5  Management  Documents.  No  new  management  documents  developed  during  this  phase. 
Existing  management  documents  should  be  reviewed  and  updated. 

14.5.4.6  Quality  Factors.  Achieving  software  quality  requires  that  quality  be  built  in  during  the 
development  process  and  evaluated  during  each  phase.  The  appropriate  quality  factors  and  quality 
measurements  should  be  prescribed  in  the  SQEP  and  procedures.  Flow-down  of  quality  factors  from 
the  SRS  to  lower-level  activities  is  a  requirement. 

14.5.4.7  Qualification/Evaluation  Requirements.  The  contractor/developer  is  required  to  monitor 
the  software  development  effort  for  consistency  with  the  SDP,  SSPM,  SCMP,  and  SQEP  and  to  notify 
the  contracting  agency  of  proposed  changes.  The  changes  are  subject  to  disapproval  by  the  contracting 
agency.  In  addition,  the  contractor/developer  shall  notify  the  contracting  agency  oi  any  actions  or 
procedures  that  deviate  from  the  SDP,  SSPM,  SCMP,  or  SQEP. 


14.5.5  Detailed  Design  Phase 

14.5.5.1  Purpose.  The  purpose  of  the  detailed  design  phase  is  to  describe  in  detail  the  structure  and 
organization  of  a  particular  CSCI  and  to  describe  the  decomposition  of  the  top-level  components  into 
low-level  components  and  units. 

14.5.5.2  Products.  The  engineering  products  produced  during  this  phase  are 

a.  Software  detailed  design  document  (SDDD)  DI-MCCR-80031 

b.  Software  test  description  (STD)  Dl-MCCR-80015 

c  Software  development  files,  informal 

d.  Informal  test  descriptions,  informal 

e.  Computer  resources  integrated  support  document  (CRiSD)  DI-MCCR-80024 

f.  Software  programmer’s  manual  (SPM)  Dl-MCCR-80021 

g.  Interface  design  document  (IDS)  DI-MCCR-80027 

h.  Data  base  design  document  (DBDD)  DI-MCCR-80028 
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14.5.5.3  Critical  Design  Review  (CDR)  and  Baseline.  The  purpose  of  the  CRD  is  to  review  the  detailed 
design,  test  description,  and  operation  and  support  documents  with  the  contracting  agency  and  to 
demonstrate  that 

a.  The  detailed  design  satisfies  the  requirement  of  the  SRS  and  the  IDSs. 

b.  The  SDDD,  IDDs,  and  DBDDs  refine  the  design  details  of  the  CSC1  in  a  manner  consistent 
with  the  STLDD. 

c.  The  STD  provides  adequate  test  cases  for  the  formal  test  identified  in  the  STP. 

d.  The  updated  versions  of  the  CSOM,  SUM,  and  CSDM  will,  in  final  form,  adequately  address 
ihe  operation  and  support  of  the  computer  system. 

e.  The  SPM,  FSM,  and  CRISD  adequately  address  software  programming  suppoit,  firmware 
support,  and  integrated  computer  resource  support. 

The  SDDD,  IDDs,  and  the  DBDDs  are  a  part  of  the  development  baseline. 

14.5.5.4  Activities,  Plans,  and  Controls.  The  contractor/developer  shall  monitor  the  development 
effor.  for  consistency  with  the  SDP,  SSPM,  SCMP,  and  SQEP  and  shall  notify  the  contracting  agency 
of  proposed  changes  to  these  documents.  The  contracting  agency  has  disapproval  authority.  In  addition, 
the  contracting  agency  must  authorize  any  actions  or  procedures  that  deviate  from  the  SDP,  SSPM, 
SCMP,  or  SQEP 

The  contractor/developer  shall  establish  the  complete,  modular,  low-level  design  for  each  CSC'I, 
and  be  refining  top-level  design  into  low-level  components  and  low-leve!  components  into  units.  Each 
unit  shall  perform  a  single  function. 

The  contrauor/developer  shall 

a.  Use  top-down  design  unless  other  methodologies  are  described  in  t'  e  SDP  and  SSPM  plans 
and  the  contracting  agency  has  reviewed  and  not  disa,  proved  the  SDP  and  SSPM  documents. 

b.  Employ  a  design  language. 

c.  Incorporate  human  factors. 

d.  Monitor  size  and  timing  estimates. 

e.  Establish  sofiw.tre  development  files. 

f.  Document  engineering  analysis  and  trade-off  studies. 

g.  Identify  test  requirements  for  informal  tests. 

h.  Describe  test  cases  for  informal  test. 

i.  Describe  test  cases  for  formal  test. 

j.  Update  CSOM,  SUM,  CSDM,  and  CRISD. 

k.  Prepare  information  to  facilitate  software  and  target  computer  compatibility. 

l.  Prepare  information  necessary  to  maintain  prmwarc. 

m.  Conduct  internal  code,  PDL,  test,  and  design  walkthroughs  and  reviews. 

14.5.5.5  Management  Documents.  No  new  management  documents  produced  during  this  phase. 
Existing  management  documents  should  be  reviewed  and  updated. 


14.5.5.6  Quality  Factors 

Achieving  software  quality  requires  that  quality  be  built  in  during  the  development  process  and 
evaluated  during  each  phase.  The  appropriate  quality  factors  and  quality  measures  should  be  prescribed 
in  the  SQEP  and  the  quality  procedures.  Flow-down  of  quality  factors  from  the  SAS  to  lower-level 
activities  is  a  requirement. 

14.5.5.7  Qualification/Quality  Evaluation  Requirements.  The  contractor/  developer  is  required  to 
monitor  the  software  development  effort  for  consistency  with  the  SDP,  SSPM,  SCMP,  and  SQEP 
and  to  notify  the  contracting  agency  of  proposed  changes  to  these  documents.  The  changes  are  subject 
to  disapproval  by  the  contracting  agency.  In  addition,  the  contractor/developer  shall  notify  the 
contracting  agency  of  any  actions  or  procedures  that  deviate  from  the  SDP,  SSPM,  SCMP,  or  SQEP. 
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14.5.6  Coding  and  Unit  Test  Phase 

14.5.6.1  Purpose.  The  objectives  of  this  phase  are  to  develop  the  code  and  demonstrate  that  the 
detailed  design  is  accurately  translated  in  code. 

14.5.6.2  Products.  The  following  engineering  products  are  developed  or  updated  during  this  phase: 

a.  Preliminary  software- test  procedure  (STPR)  DI-MCCR-80016 

b.  Source  code 

c.  Object  code 

d.  Informal  test  procedures 

e.  Informal  test  results 

f.  Update  CSOM,  SUM,  CSDM,  SPM,  and  FSM  as  required 

14.5.6.3  Formal  Design  Review  and  Baselines.  Source  code,  object  code,  test  document,  and  software 
development  files  are  placed  under  internal  configuration  management  and  become  a  part  of  the 
development  baseline.  A  formal  design  review  is  not  held  at  this  milestone. 

14.5.6.4  Activities,  Plans,  and  Controls.  The  contractor/developer’s  activities,  plans,  and  controls 
normally  consist  of  the  following 

a.  Top-down  coding  and  unit  testing  unless  other  methodologies  have  been  proposed  in  either 
the  SSPM  or  SDP  and  have  received  contracting  agency  approval.  Candidates  for  a  departure 
from  top-down  approach  are  critical  units,  government-furnished  software,  and  commercially 
available  software. 

b.  Use  of  coding  standards. 

c.  Use  of  the  software  development  folder  (SDF). 

d.  Unit  testing  will  be  controlled  by  the  test  plans  contained  in  the  STP  and  performed  in  accordance 
with  the  unit  test  cases  and  unit  test  procedures  contained  in  the  SDF. 

e.  Record  all  unit  test  results  in  the  unit  development  folder  (UDF). 

f.  Maintain  all  documents  in  a  current  status. 

g.  Develop  test  procedures  for  integration  test. 

h.  Conduct  code  and  test  in-process  reviews. 
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14.5.6.5  Management  Documents.  The  contractor/developer  shall 

a.  Update  the  SDP,  SSPM,  SCMP,  and  SEQP  as  required 

b.  Produce  internal  review  records 

c.  Produce  updated  SDFs 

14.5.6.6  Quality  Factors.  The  software  quality  metrics  and  measures  that  support  quality  factors 
evaluation  should  be  a  flow-down  from  higher-level  requirements.  The  SQEP  should  address  this  process. 

14.5.6.7  Qualification/Quality  Evaluation  Requirements.  Formal  qualification  of  components  during 
this  phase  would  only  be  performed  on  those  units  which  contain  functions  that  cannot  be  qualified 
at  the  CSC1  level.  Formal  tests  conducted  during  this  phase  require 

a.  Formal  test  procedures 

b.  Contracting  agency  approval  of  the  test  procedures 

c.  Test  performed  in  accordance  with  the  approved  test  procedures 

The  contractor/developer  is  required  to  monitor  the  software  development  effort  for  consistency 
with  the  SDP,  SSPM,  SCMP,  and  SQEP  and  to  notify  the  contracting  agency  of  proposed  changes 
to  these  documents.  The  changes  will  be  subject  to  disapproval  by  the  contracting  agency.  In  addition, 
the  contractor/developer  shall  notify  the  contracting  agency  of  any  actions  or  procedures  that  deviate 
from  the  SDP,  SSPM,  SCMP,  or  SQEP. 

14.5.7  Computer  Software  Components  (CSC)  Integration  and  Testing  Phase 

14.5.7.1  Purpose.  The  purpose  of  this  phase  is  to  integrate  units  of  code  that  have  been  entered 
in  the  development  configuration  and  to  perform  informal  tests  on  aggregates  of  integrated  units. 

14.5.7.2  Products.  The  following  products  are  normally  updated  and/or  produced  during  this  phase: 

a.  Software  test  procedures  report  (STPR)  DI-MCCR-80016 

b.  Updated  computer  operator’s  manual  (CSOM)  DI-MCCR-80018 

c.  Updated  software  user’s  manual  (SUM)  DI-MCCR-80019 

d.  Updated  computer  software  diagnostics  (CSDM)  DI-MCCR-80020 

e.  Updated  software  programmer’s  manual  (SPM)  DI-MCCR-80021 

f.  Updated  firmware  support  manual  (FSM)  DI-MCCR-80022 

g.  Source  code 

h.  Object  code 

i.  Internal  review  reports 

j.  Informal  integration  test  results 
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14.5.7.3  Test  Readiness  Review  (TRR)  and  Baseline.  The  purpose  of  the  TRR  is  to  review  the  informal 
test  results,  formal  test  procedures,  and  operations  and  support  documents  with  the  contracting  agency 
and  to  demonstrate  that 
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a.  The  CSCI  test  procedure  is  complete. 

b.  Each  CSCI  is  ready  lor  formal  test. 

c.  The  CSOM,  SUM,  and  CSDM  adequately  address  the  operation  and  support  of  the  computer 
system. 


The  TRR  is  a  formal  review  and  will  be  officially  acknowledged  by  the  contracting  agency.  MIL- 
STD-1521  A,  Appendix  F,  describes  tin  process.  The  information  and  data  produced  during  this  phase 
become  part  of  the  development  configuration. 


14.5.7.4  ActivitRs,  Plans,  and  Controls.  These  items  include  the  following 


a.  Integrate  and  test  aggregates  of  units  in  a  top-down  sequence. 

b.  Compare  memory  and  processing  time  values  with  established  allocations. 

c.  Modify,  as  necessary,  all  controlled  or  baselined  documentation  based  on  memory,  processing 
time,  and  system  resources  comparisons. 

d.  Maintain  configuration  control  over  modified  documents. 

c.  Document  the  results  of  all  integration  testing  as  described  in  the  SSPM  or  SDP. 

f.  Update  design  documentation  and  code. 

g.  Complete  detailed  procedures  from  CSCI  testing. 

h.  Conduct  internal  inprocess  reviews. 

i.  Update,  as  necessary,  the  CSDM,  SUM,  CSOM,  SPM,  and  FSM. 

14.5.7.5  Management  Documents.  No  necessary  management  documents  are  developed  during  this 
phase.  Existing  management  documents  should  be  reviewed  and  updated  as  required. 

14.5.7.6  Quality  Factors.  Achieving  software  quality  requires  that  quality  be  built  in  during  the 
development  process  and  evaluated  during  each  phase.  The  appropriate  quality  factors  and  quality 
measurements  should  he  described  in  the  SQEP  and  the  quality  procedures.  Flow-down  of  quality  factors 
from  the  SRS  to  low-level  activities  is  a  requirement. 

14.5.7.7  Qualification/Evaluation  Requirements.  Formal  qualification  of  components  during  tins 
phase  would  only  be  performed  on  those  units/CSCs  which  contain  functions  that  cannot  be  qualified 
at  the  CSCI  level.  Formal  tests  conducted  during  the  phase  sequire 

a.  Formal  test  procedures 

b.  Contracting  agency’s  approval  of  the  test  procedures 

c.  Test  performed  in  accordance  with  the  approved  test  procedures 


The  contractor/develoDer  is  required  to  monitor  the  software  development  effort  for  consistency 
with  the  SDP,  SSPM,  SCMP,  and  SQEP  and  to  notify  the  contracting  agency  of  any  proposed  changes 
to  these  documents.  The  proposed  changes  will  be  subject  to  disapproval  by  the  contracting  agency. 
In  addition,  the  contractor/ developer  shall  notify  the  contractor  agency  of  any  actions  or  procedures 
that  deviate  from  the  SD/*  '•  :’M,  SCMP,  or  SQEP. 
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14.5.8  CSCI  Testing  Phase 

14.5.8.1  Purpose.  The  objective  of  this  phase  is  to  snow  that  the  CSCI  satisfies  its  specific 
requirements,  e.g.,  functional,  interface,  performance,  and  quality. 

14.5.8.2  Products.  During  this  phase,  the  contractor/developer  normally  produces  and/or  updates 
the  following  documents: 

a.  Completed  computer  software  operator’s  manual  (CSOM) 

b.  Completed  systems  user’s  manual  (SUM) 

c.  Completed  computer  software  diagnostics  manual  (CSDM) 

d.  Completed  software  programmer’s  manual  (SPM) 

e.  Completed  firmware  support  manual  (FSM) 

f.  Version  description  document  (VDD) 

g.  Software  product  specification  (SPS) 

h.  Software  test  reports 

i.  Record  of  internal  reviews 

j.  Updated  source  and  object  code 

14.5.8.3  Audits,  Reviews,  and  Baselines.  The  purpose  of  the  functional  configuration  audit  (FCA) 
is  to  demonstrate  to  the  contracting  agency  that  the  CSCI  was  successfully  tested  and  meets  the 
requirements  of  the  SRS  and  the  IRSs.  The  FCA  also  demonstrates  to  the  contracting  agency  that  the 
CSOM,  SUM,  and  CSOM  adequately  address  the  operation  and  support  of  the  computer  system.  The 
contractor  will  present  the  CSOM,  SUM,  and  CSDM  at  the  FDA. 

The  purpose  of  the  physical  configuration  audit  (PCA)  is  to  demonstrate  to  the  contracting  agency 
that  the  SPS  is  complete  and  reflects  an  up-to-date  technical  description  of  the  CSCI.  The  contractor 
shall  present  the  SPS,  VDD,  and  source  code  at  the  PCA. 

The  configuration  identification  documents  for  HWCIs  and  CSCIs  comprise  a  system  from  a  single 
product  baseline.  When  the  FCA  and  PCA  for  each  CSCI  have  been  completed  and  authenticated 
by  the  contracting  agency,  the  SPS  for  the  CSCI  will  be  entered  into  the  product  baseline.  See  MIL- 
STD-1521B  for  information  concerning  the  FCA  and  PCA  process. 

14.5.8.4  Activities,  Plans,  and  Controls.  The  contractor/developer/IV&V  contractor  shall  test  the 
CSCI  using  formal  test  procedures  approved  by  the  contracting  agency. 

Individuals  sufficiently  independent  from  the  software  developer  shall  perform  formal  tests  on 
each  CSCI  in  accordance  with  the 

a.  Formal  test  plans 

b.  Formal  test  cases 

c.  Formal  test  procedures 

The  test  reports  accumulated  by  the  independent  test  group  shall  report  the  results  of  all  formal 
tests.  The  test  reports  shall  include 

a.  Summary  of  tests  results 


DI-MCCR-8001B 

DI-MCCR-80019 

DI-MCCR-80020 

DI-MCCR-80021 

DI-MCCR-80022 

DI-MCCR-80013 

DI-MCCR-80029 
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b.  Detail  of  test  results 

c.  Evaluation  of  test  results 

d.  Recommendations 

e.  Test  procedure  deviations. 

The  contractor/developer  shall 

a.  Make  necessary  revisions  to  the  design  documentation 

b.  Make  necessary  revisions  to  the  code 

c.  Perform  all  necessary  retests 

d.  Update  all  SDFs. 

The  contractor/developer  shall  identify  the  exact  version  of  each  deliverable  CSCI  and  the  interim 
changes  occurring  between  versions.  The  identification  shall  include 

a.  Inventory  of  materials 

b.  Inventory  of  CSCI  contents 

c.  Class  1  changes  installed 

d.  Class  2  changes  installed 

e.  Adaptation  data 

f.  Operational  description 

g.  Installation  instructions 

h.  Possible  problems  and  known  errors 

The  contractor/developer  shall  conduct  internal  in-process  reviews  during  this  phase  and  make 
all  changes  based  on  the  results  of  the  internal  review  prior  to  presenting  the  formal  test  results  and 
completed  operation  and  support  documents  to  the  contracting  agency. 

14.5.8.5  Management  Documents.  No  new  management  documents  are  developed  during  this  phase. 

14.5.8.6  Quality  Factors.  The  quality  factors  specified  in  the  software  requirements  specification 
(SRS)  apply  during  the  CSCI  testing  phase.  The  applicable  quality  factors  and  the  quality  measures 
required  to  support  the  realization  of  the  quality  factors  should  be  specified  in  the  SQEP  and  the  quality 
procedures. 

14.5.8.7  Qualification  Requirements.  The  contractor/developer  shall  conduct  formal  tests  on  each 
CSCI  to  show  that  the  CSCI  satisfies  its  specified  requirements.  Personnel  conducting  CSCI  tests  and 
analyzing  formal  test  data  shall  be  sufficiently  independent  from  the  individuals  responsible  for 
development  to  permit  objective  testing. 


14.6  SOFTWARE  QUALITY  EVALUATION 


14.6.1  Purpose 

The  purpose  of  the  software  quality  evaluation  plan  (SQEP)  is  to  describe  the  organization  and 
procedures  to  be  used  by  the  contractor  to  determine  the  quality  of  the  software  and  associated 
documentation. 

The  SQEP  is  used  by  the  government  to  monitor  the  procedures,  management,  and  work  effort 
of  the  contractors’  organizations  performing  software  quality  evaluation.  The  SQEP  and  the  quality 
procedures  are  subject  to  disapproval  by  the  contracting  agency. 

14.6.1.1  Quality  Evaluation.  The  contractor/developer  shall  perform  the  planning  and  implement 
internal  procedures  to 

a.  Evaluate  the  requirements 

b.  Evaluate  the  methodology 

c.  Evaluate  the  products 

d.  Provide  feedback  and  recommendation 

e.  Detect,  report,  and  track  problems 

The  method  for  accomplishing  the  above  shall  be  specified  in  the  SQEP. 

14.6.2  Internal  Reviews 

14.6.2.1  Internal  Reviews.  The  contractor  shall  conduct  internal  reviews  to  determine  the  following 

a.  Conformance  to  the  methodologies  proposed  in  the  contractor’s/  developer’s  planning  document 

b.  Compliance  with  the  methodologies  proposed  in  DoD-STD-2167 

c.  Adequacy  of  the  contractor’s  process  and  methodologies  to  produce  quality  products  that  will 
meet  established  requirements 

d.  Compliance  of  process  with  methodologies 

e.  Adequacy  of  in-process  reviews  to  evaluate  products 

14.6.2.2  Evaluation  Criteria.  The  contractor /developer  shall  use  the  following  evaluation  criteria: 

a.  Adherence  to  required  format 

b.  Compliance  with  contracted  requirements 

c.  Internal  consistency 

d.  Understandability 

e.  Technical  adequacy 


14.6.2.3  Internal  Reviews— All  Phases.  The  contractor/developer  shall  conduct  the  following  reviews 
during  all  phases  of  the  software  development  cycle. 

a.  Review  newly  prepared  or  revised  SDP,  SSPM,  SCMP,  and  SQEP  for 

1 .  Adherence  to  required  format 

2.  Compliance  with  contracted  requirements 

3.  Internal  consistency 

4.  Understandability 

5.  Technical  adequacy 

6.  Degree  of  completeness 

b.  Review  the  activities  and  the  tools,  procedures,  and  methodologies  employed  during  the  phase 
for  consistency  with  the  contractor’s  software  development  plans.  Included  in  this  review  shall 
be  evaluation  of 

1 .  Software  configuration  management 

2.  Software  development  library 

3.  Documentation  contract 

4.  Storage  and  handling  of  media 

5.  Control  of  nondeliverables 

6.  Risk  management 

7.  Corrective  action 

8.  Conformance  to  standards  and  procedures 

14.6.3  Internal  Review— Software  Requirements  Analysis 

The  contractor/developer  shall  conduct  internal  reviews  during  the  software  requirements  phase. 

14.6.3.1  The  OCD  shall  be  reviewed  for 

a.  Adherence  to  required  format 

b.  Compliance  with  contractual  requirements 

c.  Internal  consistency 

d.  Understandability 

e.  Technical  adequacy 

f.  Degree  of  completeness 

g.  Consistency  with  the  SSS 

h.  High-level  understanding 

14.6.3.2  The  ongoing  SRS  and  IRSs  shall  be  reviewed  for 
a.  Adherence  to  required  format 
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b.  Compliance  with  contractual  requirements 

c.  Internal  consistency 

d.  Understandability 

e.  Technical  adequacy 

f.  Degree  of  completeness 

g.  Traceability  of  requirements  to  system  specification 

h.  Consistency  of  interface  requirements  with  specifications  for  interfacing  elements 

i.  Consistency  of  SRS  and  IRSs  with  one  another 

j.  Testability  of  functional,  performance,  and  interface  requirements 


14.6.3.3  The  following  management  documents  shall  be  reviewed  for  adequate  control,  technical 
feedback,  and  management  feedback: 

a.  Software  configuration  management 

b.  Software  development  library 

c.  Documentation  control 

d.  Storage  and  handling  of  media 

e.  Control  of  nondeliverables 

f.  Risk  management 

g.  Corrective  action 

h.  Conformance  to  all  approved  standards  and  procedures 
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14.6.4  Internal  Review— Preliminary  Design 

14.6.4.1  Process.  The  contractor/developer  shall  conduct  internal  reviews  during  the  preliminary 
design  phase.  The  process  shall  be  reviewed  for  adequate  performance  in  the  following  areas: 

a.  Software  configuration  management 

b.  Software  development  library 

c.  Documentation  control 

d.  Storage  and  handling  of  media 

e.  Control  of  nondeliverables 

f.  Risk  management 
g  Corrective  action 

h.  Conformance  to  all  approved  standards  and  procedures 


14.6.4.2  General  Product  Reviews.  All  products  shall  be  reviewed  for 

a.  Adherence  to  required  format 

b.  Compliance  with  contractual  requirements 
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c.  Internal  consistency 

d.  Understandability 

e.  Technical  adequacy 

f.  Degree  of  completeness 

14.6.4.3  Specific  Product  Reviews.  The  specific  products  shall  be  reviewed  for  the  following 
characteristics. 

a.  The  top-level  design  and  STLDD  shall  be  reviewed  for  <  'aceability  to  the  SRS  and  IDRs. 

b.  The  STP  shall  be  reviewed  for 

1.  Adequate  te^t  coverage 

2.  Consistency  with  the  SPP 

3.  Adequate  p’r.nning 

The  piciiminary  versions  the  CSOM,  SUM,  and  CSDM  will  be  reviewed  for 
I  Cwnr-.aei'cy  with  SRS 

2.  Aj’pj- .friate  content 

3.  consistency  with  one  another 

d.  The  preliminary  CRISD  shall  be  reviewed  for 

1.  Consistency  with  government  support  concepts 

2.  Adequacy  of  support  planning 

14.6.5  Internal  Review— Detailed  Design 

14.6.5.1  Process.  The  contractor /developer  shall  conduct  internal  reviews  during  the  detailed  design. 
Tne  process  shall  be  reviewed  for 

a.  Software  configuration  management 

b.  Software  development  library 

c.  Documentation  control 

d.  Storage  and  handling  of  media 

e.  Control  of  nondeliverables 

f.  Risk  management 

g.  Corrective  action 

h.  Conformance  to  all  approved  standards  and  procedures 

14.6.5.2  General  Product  Reviews.  All  products  shall  be  reviewed  for 

a.  Adherence  to  required  format 

b.  Compliance  with  contractual  requirements 


c.  Internal  consistency 

d.  Understandability 

e.  Technical  adequacy 

f.  Degree  of  completeness 


14.6.5.3  Specific  Product  Reviews.  The  specific  products  shall  be  reviewed  for  the  following 
'’•.aracteristics. 


a.  Review  of  evolving  detailed  design  and  the  SDDD,  IDDs,  and  DBDDs,  as  applicable  for 

1.  Traceability  to  SRS,  IRS,  and  Slt.DD 

2.  Use  of  appropriate  design  techniques 

3.  Consistency  with  one  another 


b.  Review  one  STP  for 


1 .  Adequate  test  coverage 

2.  Consistency  with  design 

c.  Review  software  development  files  for  accuracy  of  schedule  and  status. 


d.  Review  ur-.it  test  cases  for 


1.  Traceability  to  the  STP 

2.  Adequate  test  coverage 

3.  Consistency  with  design 

e.  Review  integration  test  cases  for 

1 .  Traceability  to  the  STP 

2.  Adequate  test  coverage 

3.  Consistency  with  design  documentation 

f.  Review  the  updated  CSOM,  SUM,  and  CSDM  for 

1 .  Consistency  with  requirements  and  design 

2.  Appropriateness  of  content 

3.  Consistency  with  one  another 

g.  Review  the  completed  CRISD  for 

1.  Consistency  with  government  support  concepts 

2.  Adequacy  of  support  planning 

h.  Review  the  SPM  and  FSM  for 


1 .  Consistency  with  design  documentation 

2.  Appropriateness  of  content  for  support  personnel 
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14.6.6  Internal  Review— Code  and  Unit  Testing 


14.6.6.1  Process.  The  contractor/developer  shall  conduct  internal  reviews  during  the  code  and  t  lit 
testing  phase.  The  process  shall  be  reviewed  for 


a.  Software  configuration  management 

b.  Software  development  library 

c.  Documentation  control 

d.  Storage  and  handling  of  media 

e.  Control  of  nondeliverables 

f.  Risk  management 

g.  Corrective  action 

h.  Conformance  to  all  approved  standards  and  procedures 


14.6.6.2  General  Product  Reviews.  All  products  shall  be  reviewed  for 

a.  Adherence  to  required  format 

b.  Compliance  with  contractual  requirements 

c.  Internal  consistency 

d.  Understandability 

e.  Technical  adequacy 

f.  Degree  of  completeness 


14.6.6.3  Specific  Product  Reviews.  The  specific  products  shall  be  reviewed  for  the  following 
characteristics: 


a.  The  evolving  and  completed  source  code  shall  be  reviewed  for 

1 .  Compliance  with  coding  standards 

2.  Traceability  to  detailed  design 

b.  The  software  development  files  shall  be  reviewed  for 

1.  Accuracy  of  status  and  schedule 

2.  Unit  test  procedures 

3.  Unit  test  results 

4.  Traceability  to  unit  test  plans 

5.  Traceability  to  unit  test  cases 

6.  Readiness  for  units  to  be  placed  under  CM 

c.  The  STLDD,  SDDD,  IDDs,  and  DBDDs,  as  applicable,  shall  be  reviewed  for 

1.  Traceability  to  SRS 

2.  Use  of  appropriate  design  techniques 

3.  Consistency  with  one  another 
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d.  The  updated  source  code,  as  applicable,  shall  be  reviewed  for 

1.  Compliance  with  coding  standards 

2.  Consistency  with  the  updated  detailed  design  documentation 

e.  The  informal  integration  test  procedures  shall  be  reviewed  for 

1.  Traceability  to  CSC  integration 

2.  Adequate  test  coverage 

3.  Consistency  with  design  documents 

f.  The  preliminary  design  STPR  shall  be  reviewed  for 

1.  Traceability  to  the  STP  and  STD 

2.  Adequate  test  coverage 

3.  Consistency  with  design  documents 

g.  The  updated  CSOM,  SUM,  and  CSDM  shall  be  reviewed  for 

1.  Consistency  with  requirements  and  design  documents 

2.  Appropriateness  of  content 

3.  Consistency  with  one  another 

h.  The  updated  SPM  and  FSM  shall  be  reviewed,  as  applicable,  for 

1.  Consistency  with  design  documentation 

2.  Appropriateness  of  content  for  support  personnel 

14.6.7  Internal  Review-CSC  Integration  and  Testing 

14.6.7.1  Process.  The  contractor/developer  shall  conduct  internal  reviews  during  the  CSC  integration 
testing  phase.  The  process  will  be  reviewed  for 

a.  Software  configuration  management 

b.  Software  development  library 

c.  Documentation  control 

d.  Storage  and  handling  of  media 

e.  Control  of  nondeliverables 

f.  Risk  management 

g.  Corrective  action 

h.  Conformance  to  all  approved  standards  and  procedures 

14.6.7.2  General  Product  Review.  All  products  shall  be  reviewed  for 

a.  Adherence  to  required  format 

b.  Compliance  with  contractual  requirements 


c.  Internal  consistency 

d.  Understandability 

e.  Technical  adequacy 

f.  Degree  of  completeness 

14.6.7.3  Specific  Product  Reviews.  The  specific  product  shall  be  reviewed  for  the  following 
characteristics: 

a.  The  informal  test  results  of  CSC  integration  will  be  reviewed  for 

1.  Traceability  to  CSC  test  cases 

2.  Traceability  to  CSC  test  procedures 

3.  Correct  performance  of  the  integrated  CSCI 

4.  Readiness  for  the  CSCI  to  undergo  formal  testing 

b.  The  updated  STLDD,  SDDD,  IDDs,  and  DBbDs  shall  be  reviewed  for 

1.  Traceability  to  sc  It  ware  requirements 

2.  Use  of  appropriate  design  techniques 

3.  Consistency  with  one  another 

c.  The  source  code  shall  be  reviewed  for 

1.  Compliance  with  coding  standards 

2.  Consistency  with  update  design  documentation 

d.  The  updated  software  development  files  shall  be  reviewed  for  accuracy  of  status  and  schedule 

e.  The  completed  STPR  shall  be  reviewed  for 

1.  Traceability  to  the  STP  and  STD 

2.  Adequate  test  coverage 

3.  Consistency  with  design  documentation 

f.  The  updated  CSOM,  SUM,  and  CSDR  shall  be  reviewed  for 

1.  Consistency  with  requirements  and  design  documentation 

2.  Appropriateness  of  content 

3.  Consistency  with  one  another 

g.  The  updated  SPM  and  FSM  shall  be  reviewed  for 

1.  Consistency  with  design  documentation 

2.  Appropriateness  of  content  for  support  personnel 


14.6.8  Internal  Review— CSCI  Testing 


14.6.8.1  Process.  The  contractor/developer  shall  conduct  internal  reviews  during  the  CSCO  testing 
phase.  The  process  will  be  reviewed  for 

a.  Software  configuration  management 

b.  Software  development  library 

c.  Documentation  control 

d.  Storage  and  handling  of  media 

e.  Control  of  nondeliverables 

f.  Risk  management 

g.  Corrective  action 

h.  Conformance  to  all  approved  standards  and  procedures 

14.6.8.2  General  Product  Review.  All  products  shall  be  reviewed  for 

a.  Adherence  to  required  format 

b.  Compliance  with  contractual  requirements 

c.  Internal  consistency 

d.  Understandability 

e.  Technical  adequacy 

f.  Degree  of  completeness 

14.6.8.3  Specific  Product  Review.  The  specific  products/activities  shall  be  reviewed  for  the  following 
characteristics. 

a.  The  CSCI  testing  shall  be  monitored  to  ensure  that 

1.  It  is  performed  using  the  current  controlled  version  of  the  code 

2.  It  is  conducted  in  accordance  with  approved  test  plans,  descriptions,  and  procedures 

3.  Necessary  retesting  is  accomplished 

b.  The  STRs  shall  be  reviewed  for  traceability  of  the  CSCI  test  results  to  the  CSCI  test  plans, 
test  cases,  and  test  procedures 

c.  The  updated  STLDD,  SDDD,  IDDs  and  DBDDs,  as  applicable,  shall  be  reviewed  for 

1.  Traceability  to  software  requirements 

2.  Use  of  appropriate  design  techniques 

3.  Consistency  with  one  another 

d.  The  updated  source  code,  as  applicable,  shall  be  reviewed  for 

1 .  Compliance  with  coding  standards 

2.  Consistency  with  the  updated  detailed  design  documentation 


e.  The  software  development  files  shall  be  reviewed  for  accuracy  of  status  and  schedule. 

f.  The  SPS  shall  be  reviewed  for  incorporation  of  design  documentation  and  software  listings  con¬ 
sistent  with  the  “as-built”  software. 

g.  The  VDD  shall  be  reviewed  for  accuracy  in  reflecting  the  exact  version  of  each  CSCI. 

h.  The  completed  CSOM,  SUM,  and  CSDM  shall  be  reviewed  for 

1 .  Consistency  with  the  SPS 

2.  Appropriateness  of  content 

3.  Consistency  with  one  another 

i.  The  SPM  and  FSM  shall  be  reviewed  for 

1 .  Consistency  with  design  documentation 

2.  Appropriateness  of  content 

14.6.9  Evaluation 

14.6.9.1  Formal  Reviews  and  Audits.  The  contractor/developer  shall  evaluate  the  planning  and 
preparation  performed  for  each  formal  review  and  audit  to  ensure  that 

a.  Required  products  (e.g.  the  data  package)  will  be  available  for  review 

b.  Necessary  resources  and  material  are  available 

c.  Meeting  agenda  is  coordinated 

d.  Cochairpersons  are  designated 

e.  Action  items  and  action  items  sources  are  recorded 

The  following  formal  design  reviews  and  audits  are  normally  conducted  during  the  system  life  cycle: 

a.  System  requirement  reviews  (SRR) 

b.  System  design  review  (SDR) 

c.  Software  specification  review  (SSR) 

d.  Preliminary  design  review  (PDR) 

e.  Critical  design  review  (CDR) 

f.  Test  readiness  review  (TRR) 

g.  Functional  configuration  audit  (FCA) 

h.  Physical  configuration  audit  (PCA) 

i.  Formal  qualification  review  (FQA) 

j.  Production  readiness  review  (PRR) 

14.6.9.2  Evaluation  of  Subcontractor  Products.  Prior  to  accepting  software  or  documentation 
developed  from  a  subcontractor,  the  prime  contractor  shall  evaluate  the  products  for 

a.  Completeness 


b.  Technical  adequacy 

c.  Compliance  with  subcontract  requirements 

14.6.9.3  Quality  Records.  The  contractor/developer  shall  prepare  and  maintain  records  of  each  quality 
evaluation  performed;  quality  records  shall  identify 

a.  Date  of  evaluation 

b.  Evaluation  participants 

c.  Items  or  activities  reviewed 

d.  Objectives  of  the  evaluation 

e.  Detected  problems 

f.  Recommendations 

14.6.9.4  Quality  Reporting.  The  contractor/developer  shall  prepare  reports  that  provide  to  contractor 
management  the  results  and  recommendations  from  the  quality  evaluations.  The  quality  evaluation 
reports  shall  identify 

a.  Evaluation  activity 

b.  Detected  problems 

c.  Remedial  action 

d.  Trends 

e.  Recommended  changes 

14.6.9.5  Corrective  Action  System.  The  contractor/dcveloper  shall  implement  a  corrective  action 
system  for  all  software  and  documentation  that  has  been  placed  under  contractor  or  government  control. 
The  corrective  action  system  shall  include  provisions  for 

a.  Reporting  problems 

b.  Analyzing  problems 

c.  Classifying  problems  by  category  and  priority 

d.  Identifying  corrective  action 

e.  Identifying  trends 

f.  Analyzing  trends 

g.  Authorizing  corrective  action 

h.  Implementing  corrective  action 

i.  Reevaluating  the  problem  after  corrective  action 

j.  Tracking  problems 

k.  Closing  out  problems 

l.  Providing  government  visibility  into  critical  problems  based  on  categorization,  priority  schemes, 
and  problems/change  reports 
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14.6.9.6  Quality  Cost  Data.  The  contractor/developer  shall  collect  and  analyze  the  document  data 
relative  to  the  cost  of  detecting  and  correcting  errors  in  all  software  and  documentation  that  have  been 
placed  under  contractor  or  government  control.  The  specific  data  to  be  collected  and  the  analyses  to 
be  performed  shall  be  proposed  by  the  contractor  in  either  the  SQEP  or  the  SDP  and  shall  be  subject 
to  contracting  agency  approval. 

14.6.9.7  Products — Software  Quality  Evaluation.  The  following  are  included  in  the  quality  evaluation 
considerations: 


a.  Quality  records.  The  contractor/developer  shall  prepare  and  maintain  records  of  each  quality 
evaluation. 
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b.  Quality  reports.  The  contractor  shall  prepare  and  maintain  reports  that  summarize  the  results 
and  recommendations  of  quality  evaluations  performed.  These  reports  shall  be  made  available 
for  government  review. 

c.  Certification.  The  contractor/developer  shall  collect  and  make  available  for  government 
inspection  evidence  indicating  the  compliance  with  the  requirements  of  the  contract. 

d.  Independence.  Each  software  quality  evaluation  shall  be  performed  by  individuals  who  have 
sufficient  responsibility,  authority,  resources,  and  independence  to  accomplish  objective 
evaluation  of  the  products  and  activities  being  evaluated.  The  degree  of  evaluation  independence 
shall  be  specified  in  the  SQEP  or  SDP. 

« 

14.6.10  Software  Project  Planning  and  Control 

14.6.10.1  Sizing  and  Timing.  The  contractor/developer  shall  derive  sizing  and  timing  parameters 
for  each  CSCI  including  minimum  reserve  capacities.  The  contractor  will  monitor  these  parameters 
and  reallocate  as  necessary  to  meet  requirements  specified  in  the  SRS. 

14.6.10.2  Status  and  Cost  Report.  The  contractor  /developer  shall  maintain  cost  and  schedule  forecast, 
analysis,  and  reports.  These  reports  shall  conform  to  the  WBS. 

14.6.10.3  Test  Documentation  Control.  The  contractor/developer  shall  establish  internal  control 
over  approved  STP,  STD,  and  STPRs.  The  contracting  agency  shall  be  notified  of  any  proposed  changes 
to  these  documents,  and  the  contractor  shall  obtain  approval  before  making  any  changes. 

14.6.10.4  Software  Development  Library.  The  contractor/developer  shall  establish,  implement,  and 
control  the  content  of  the  software  development  library. 

14.6.10.5  Risk  Management.  The  contractor/developer  shall  establish  and  implement  the  risk 
management  procedures  specified  in  the  SDP  for  controlling  risk.  The  procedures  shall  include 

a.  Identifying  the  risk  areas  and  the  consistent  risk  factors  in  each  area 

b.  \ssessing  the  probability  of  occurrence  and  the  potential  damage  associated  with  each  risk  factor 

c.  Assigning  appropriate  resources  to  reduce  the  risk  factors 

d.  Identifying  and  analyzing  the  alternatives  available  for  reducing  the  risk  factors 

e.  Selecting  the  most  promising  alternative  for  each  risk  factor 

f.  Planning  implementations  of  the  selected  alternatives  for  each  risk  factor 

g.  Obtaining  feedback  to  determine  the  success  of  the  risk  reducing  action  for  each  risk  factor 
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SECTION  15 

TEST  AND  EVALUATION 


15.1  INTRODUCTION 


15.1.1  References 

MIL-STD-188C,  Technical  Standards  for  Military  Communication  Systems 
MIL-STD-210B,  Standard  for  Climatic  Extremes 
MIL-STD-490A,  Standard  for  Specification  Practices 
MIL-STD-810,  Environmental  Test  Methods  and  Engineering  Guidelines 
MIL-E-16400G,  General  Specification  for  Naval  Ship  and  Shore  Electronic,  Interior 
Communications,  and  Navigation  Equipment 
NAVSO  P-2457,  Department  of  the  Navy  RDT&E  Management  Guide 
NAVMAT  P-9492,  Navy  Manufacturing  Screening  Program 
OPNAVINST  3960.10,  Test  and  Evaluation 
OPNAVINST  5000.42,  RDT&E/Acquisition  Procedure 
NOSC  TD  108  Project  Manager’s  Guide 
NAVSEA,  System  Acquisition  T&E  Handbook 
NAVSPAWAR,  T&E  Handbook,  3rd  edition 


15.1.1  Summary 


Successful  Test  and  Evaluation  (T&E)  is  the  major  determining  factor  in  program  acquisition 
milestone  decisions.  This  is  true  at  any  time,  but  especially  during  the  acquisition  process.  This 
presentation  is  not  intended  to  make  Test  Directors  of  each  of  you,  but  rather  to  present  and  review 
pertinent  T&E  information  for  program  managers.  Required  T&E  documents  are  identified,  including 
Test  and  Evaluation  Master  Plans  (TEMPS),  test  plans,  procedures  and  reports.  Considerations  to 
be  evaluated  during  site  selections  are  listed.  The  purposes  for  a  technical  evaluation  (TECHEVAL) 
and  an  operational  evaluation  (OPEVAL)  are  presented,  as  well  as  the  OPEVAL  Readiness  Criteria. 
T&E  services  and  capabilities  provided  by  Support  Engineering,  Code  95,  are  reviewed,  and  examples 
of  some  NOSC  programs  are  discussed. 


15.2  DEFINITIONS 


ACAT 
D/V  (D&V) 
DT  I 
DT  II 
ADM 


Acquisition  category 

Demonstration  and  Validation,  phase  I 

Developmental  Testing  during  D/V  phase 

Developmental  Testing  during  Full-Scale  Development,  phase  II 

Advanced  Development  Model 
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EDM 

Engineering  Development  Model 

FSD 

Full-Scale  Development 

FSP 

Full-Scale  Prototype 

FOT&E 

Follow-on  T&E 

MS 

Milestone 

OT 

Operational  Test 

OPEVAL 

Operational  Evaluation 

TECHEVAL 

Technical  Evaluation 

PAT&E 

Production  Acceptance  T&E 

15.3  T&E  DURING  THE  ACQUISITION  PROCESS 

There  are  four  phases  during  the  acquisition  process:  Conceptual— phase  n,  Demonstration  £ 
Validation — phase  I,  Full-Scale  Development — phase  II,  and  Production  and  Deployment — phase  III. 
The  decision  to  proceed  from  one  phase  to  the  next  is  determined  at  meetings  held  by  Defense  Systems 
Acquisition  Review  Councils  (DSARCs);  this  is  where  the  milestone  decisions  are  made.  The  results 
of  T&E,  Test  Reports,  and  data  are  the  major  determining  factors  effecting  the  milestone  decisions. 

15.3.1  Milestone  I  (MS-I) 

There  is  little  if  any  T&E  to  support  MS-I  (usually  studies)  unless  the  project  is  using  some  new 
state-of-the-art  technology.  If  so,  some  tests  may  be  required  to  verify  tne  feasibility  of  using  such 
technology. 

15.3.2  Milestone  II  (MS-II) 

MS-II  is  based  upon  the  DT-I  and  OT-I  performed  during  the  D/V,  phase  I.  Again,  the  extent 
of  testing  is  determined  by  the  technology  used.  Current  technology  requires  less  T&E  than  “state-of- 
the-art.”  These  tests  are  usually  conducted  on  advanced  development  models  (ADMs)  and  require 
appropriate  test  documentation.  In  the  past  there  has  been  little  if  any  OT-I  testing,  but  recently  a  memo 
from  the  office  of  the  Secretary  of  Defense  has  stated  a  need  for  OT  involvement  prior  to  MS-II. 
When  writing  the  TEMP,  during  the  conceptual  phase  or  early  in  the  demonstration  and  validation 
phase,  it  is  necessary  to  make  contact  with  the  OPTEVFOR  people.  OPTEVFOR  is  responsible  for 
the  development  of  part  IV  of  the  TEMP,  the  OT&E  outline.  This  is  the  time  to  get  acquainted  with 
the  operational  test  director  and  to  build  up  a  rapport,  which  will  work  to  your  advantage  because 
the  OPEVAL  report  is  a  major  influence  as  to  whether  your  system  will  be  approved  for  service  use. 

15.3.3  Milestone  III  (MS-III) 

The  decision  to  go  into  production,  MS-III,  is  based  on  the  results  of  DT-II  and  OT-II  testing. 
These  tests  are  performed  on  full-scale  prototype  units  or  engineering  development  models  (EDMs). 
These  units  should  be  similar  to  the  production  units  to  reduce  the  risks  of  having  the  production  units 


fail.  Similarity  may  also  eliminate  some  of  the  required  first  article  tests.  Several  tests  are  conducted 
in  parallel  (i.e.,  environmental,  performance,  reliability,  etc.),  and  some  tests  are  destructive  (shock, 
salt  spray,  fungus,  etc.).  Therefore,  a  number  of  test  units  may  be  required.  The  size  of  the  system 
(program  product),  cost,  and  schedule  will  all  have  a  bearing  upon  the  quantity  of  test  units  planned. 

15.3.3.1  TECHEVAL.  The  last  test  of  DT-II  is  usually  the  TECHEVAL.  Specific  documentation 
is  required  for  the  TECHEVAL,  test  plans,  procedures,  and  the  TECHEVAL  Test  Report.  The  purpose 
of  a  TECHEVAL  is  to  accomplish  the  following 

Verify  that  the  system  meets  its  technical  performance  requirements 

Verify  compatibility  with  other  systems  and  operational  environment 

Verify  that  the  system  is  operationally  satisfactory  and  ready  for  OPEVAL 

15.3.3.2  OPEVAL.  OT-II  consists  of  an  operational  test  conducted  by  an  independent  agency, 
OPTEVFOR,  using  military  operators  of  the  quantity  and  rates  planned  for  use  in  the  Fleet.  This  Navy 
crew  shall  have  been  trained  by  the  curriculum  developed  for  this  program.  Prior  to  entering  OPEVAL, 
a  system  must  meet  the  OPEVAL  readiness  criteria,  which  consists  of 

TEMP  being  current  and  approved 

DT-II  completed  and  reports  published 

All  DT&E  objectives  and  performance  thresholds  met 

Engineering  complete  and  all  “ilities”  satisfactory 

System  expected  to  perform  successfully  in  OPEVAL 

System  maintenance  documents,  logistics  support  plan,  failure  mode  and  effects  analysis  (FMEA), 
life-cycle  cost  (LCC),  and  logistic  support  analysis  supplied  to  OPTEVFOR 

Spare  parts  available  for  OPTEVFOR 

Navy  training  plan  approved  and  provided  to  OPTEVFOR 

OPEVAL  crew  consists  of  n  imbers  and  rates  planned  for  the  Fleet  and  training  completed 
All  OPEVAL  resources  listed  in  the  TEMP  available 
The  safety  program  satisfactorily  completed 


15.4  CRITICAL  T&E  DOCUMENTS 

The  Test  and  Evaluation  Master  Plan  (TEMP)  is  probably  the  most  important  T&E  document, 
followed  by  an  overall  Navy  Test  Plan,  a  system  performance  specification,  and  other  plans  and 
procedures.  A  T&E  Management  Plan  may  be  required,  depending  upon  the  size  ot  the  program.  For 
smaller  programs,  the  T&E  management  information  and  responsibilities  are  contained  in  the  Navy 
Test  Plan. 

Environmental  test  plans  and  procedures  are  required  to  verify  the  requirements  identified  in  the 
quality  section  of  the  specification.  A  test  requirements  document  may  be  required  depending  upon 
the  size  of  the  program  and  the  number  of  official  specifications.  For  the  larger  programs,  a  test 
requirements  document  (TRD)  is  required,  especially  if  there  are  a  number  of  applicable  specifications. 
This  document  lists  all  the  test  requirements  and  references  the  specification  or  specifications  from 
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which  the  requirement  came.  A  TRD  makes  it  much  easier  to  keep  a  handle  on  the  fest  requirements 
and  to  be  sure  that  none  of  them  is  neglected  or  falls  through  the  cracks. 

Another  critical  T&E  document  is  the  TECHEVAL  plan.  It,  along  with  procedures,  is  necessary 
for  a  successful  TECHEVAL.  Many  of  the  other  previously  identified  plans  will  also  require  procedures. 
For  smaller  projects,  the  plan/procedures  can  be  one  document.  All  of  these  tests  require  reports  that 
document  the  results.  Test  reports  provide  the  supporting  data  to  keep  a  project  moving  from  phase 
to  phase  at  the  various  milestones. 


15.5  TEST  PLANNING 

Test  planning  documents  are  required  to  assure  ourselves,  the  program  manager,  and  the  sponsors, 
that  all  functions  will  be  verified. 


15.5.1  Test,  and  Evaluation  Master  Plan 


The  Test  and  Evaluation  Master  Plan  (TEMP)  is  the  first  test  plan  for  the  program  to  be  developed. 
This  should  ha  done  during  the  Conceptual  Phase,  prior  to  MS-I,  or  early  in  the  D/V  phase.  The  purposes 
of  a  TEMP  a.  c  to 

Define  and  control  adequate  T&E 

Specify  design  criteria  and  evaluation  processes 

Identify  critical  T&E  issues 

Identify  and  reserve  the  required  special  resources 

Document  major  agreements  between  the  SYSCOM  and  OPTEVFOR 

The  TEMP  consists  of 

Cover  Page 

TEMP  number 
Title 

Program  Elements 
Development  Command 
Operational  Test  Agency 
Review  and  approval  signatures 

Administrative  Information 
Primary  Points  of  Contact 

Name,  organization,  phone  number 

Part  I,  System  Details 
Mission  Description 
System  Description 
Required  Technical  Characteristics 
Required  Operational  Characteristics 

Part  II,  Program  Summary 

Management,  outline  of  responsibilities 
Integrated  Schedule 
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Part  III,  DT&E  Outline 

Critical  Technical  Characteristics 
DT&E  to  Date 
Special  Retest  Requirements 
Future  DT&E 

Part  IV,  OT&E  Outline 

Critical  Operational  Issues 
OT&E  to  Date 
Future  OT&E 

Part  V,  T&E  Resource  Summary 
Test  Articles 
Test  Sites 

Support  Equipment 
Consumables 

Manpower  requirements/training 
Resource  Schedule 

Additional  Appendices  as  required 


15.5.2  Test  Plans 


As  usual  there  are  a  number  of  formats  for  test  plans  or  “many  ways  to  skin  a  cat.”  This  outline 
includes  all  the  required  elements  and  will  give  you  a  checklist  for  any  plan: 

Introduction-objectives 

Scope 

Test  support 

Installation  &  checkout  (I&C) 

Test  conditions  &  criteria 
Test  methods 
Test  schedule 

Test  documentation,  procedures,  reports 


15.5.3  Site  Selection 

The  selection  of  a  test  site  is  dependent  upon  the  type  of  tests  required.  The  selection  is  a  process 
of  getting  the  best  combination  of  environments,  while  considering  costs. 

Why  use  a  land-based  site  versus  at-sea  testing? 

Less  expensive  and  enables  controlled  tests 
Reduces  risks  for  final  at-sea  tests 
Frees  up  ships 

Wide  range  of  permutations  available 

Knowledgeable  test  team  available  and  provides  training  for  ship  crews 

Allows  stressing  the  system 

OPTEVFOR  involvement  (upon  PA  request) 

Validation  of  I&C  procedures 
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15.6  CONDUCTING  THE  TESTS 


The  testing  periods  are  usually  just  prior  to  the  milestone  decisions.  There  is  very  little,  if  any, 
testing  before  MS-I.  The  amount  of  testing  on  advanced  development  models  (ADMs)  is  dependent 
on  the  type  of  technology  being  used— little  testing  for  current  technology  and  more  for  newer 
technologies.  The  full-scale  development  phase  is  the  primary  test  period.  This  is  where  the  developing 
agency  must  determine  if  the  system  is  ready  for  OPEVAL  and  satisfies  the  criteria  of  “ready  fo- 
OPEVAL.” 

15.6.1  Test  Team  Selection 

Selection  of  a  Navy  test  director  early  in  the  program  is  essential.  It  identifies  an  individual 
responsible  for  T&E  activities,  provides  continuity  to  the  program,  and  gives  the  program  manager 
a  single  point  oi  contact  for  T&E  status.  When  selecting  a  test  team,  maintain  a  continuity  of  personnel: 
use  people  that  participated  in  the  development  of  the  test  requirements  documents  or  test  plans.  The 
key  personnel  should  have  had  some  past  experience  and  should  include  some  equipment  specialists. 
Get  some  support  from  the  developer  and  invite  OPTEVFOR  to  participate  or  observe. 


15.6.2  Conduct 

When  conducting  the  tests,  know  what  data  are  required  to  verify  performance.  Be  familiar  w  ith 
the  test  procedures;  they  should  be  dry-run  before  an  official  test  run.  Provide  data  sheets;  use  them! 
Maintain  an  operating  log  of  all  operations  and  identify  individuals  who  make  entries. 


15.6.3  Reporting 

Document  the  results  of  all  tests.  A  trick  of  making  sure  you  get  the  necessary  data  is  to  start 
the  test  report  before  you  start  the  test.  Once  you  see  the  holes  in  the  report  you  can  determine  the 
data  required  to  fill  them.  Collect  all  the  data  during  and  after  testing  and  provide  copies  of  supporting 
data  with  the  test  report.  Explain  how  the  data  analysis  was  accomplished  and  make  recommendations. 


15.6.4  Environmental  Testing 


Environmental  testing  consists  of  testing  the  system  under  the  various  conditions  it  would  encounter 
in  actual  operation.  Environmental  tests  cover 


Low  temperature 

Humidity 

Sunshine 

Wind  velocity 

Hydrostatic  pressure 

Dust 

Thermal  shock 
Shock 


High  temperature 

Salt  fog 

Fungus 

Icing 

Altitude 

Rain 

Transportability 

Vibration 
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15.7  NOSC  TEST  FACILITIES 


Building  29,  sometimes  known  as  the  “test  huts,”  houses  most  of  the  environmental  test  capabilities. 
It  also  houses  the  System  Test  Branch. 

The  Artie  Laboratory  has  numerous  high-pressure  test  vessels,  as  well  as  the  capability  for  growing 
artic  ice. 

Buildings  600  and  605  are  two  large  RFI  enclosures,  each  having  the  capability  to  do  large  system 
testing.  They  ;;:so  have  computer  support  capabilities. 

Bayside  Las  the  Dolphin  submarine  and  does  other  underwater  testing.  Bayside  also  does  torpedo 
and  materials  testing. 

San  Clemente  Island  has  a  missile  test  range  and  an  underwater  test  range. 

Morris  Dam  also  does  torpedo  testing. 

15.7.1  Code  951  Capabilities 

The  Electronic  and  Environmental  Test  Branch,  Code  95 1 ,  has  the  capability  to  conduct  first  article 
acceptance  and  performance  testing  of  almost  any  radio  receiver  cr  transmitter  and  numerous  other 
electronic  equipment. 

Four  shielded  enclosures  are  available  to  enable  testing  without  external  interference.  Two  enclosures 
are  ducted  together  to  enable  the  test  stimulus  and  the  unit  under  test  to  be  shielded  from  each  other. 
The  largest  enclosure  is  20  by  24  by  15  feet. 

Three  vibration  machines  for  electronic  equipment  testing  are  available  with  capability  for  loads 
up  to  620  pounds  and  frequencies  from  5  to  2500  Hz. 

Two  mechanical  vibration  machines  are  available,  primarily  for  mechanical  and  shipboard  vibration 
testing.  They  have  a  load  capacity  up  to  10,000  pounds  and  frequencies  from  5  to  40  Hz, 

Shock  machines  are  capable  of  loads  up  to  6000  pounds  and  up  to  2000  g’s. 

Five  climatic  chambers  are  available  to  simulate  environments  of  temperature,  humidity,  and 
altitude. 

15.7.2  Code  954  Capabilities 

The  Systems  Test  and  Evaluation  Branch,  Code  954,  provides  the  following  services: 

Provides  Navy  test  directors  for  programs 
Develops  quality  sections  of  specifications 
Drafts  TEMPs 

Develops  test  plans  and  procedures 

Conducts  tests 

Develops  test  reports 

Monitors  contractors 

Provides  test  consultation 

Reviews  procurement  packages  (T&E  aspect) 

Supports  Design  Reviews 


15.8  PROJECT  EXAMPLES 


15.8.1  SCIACT  (Secure  Communication  Integration  of  the  AN/GSC40  Command  Post 
Terminal) 

The  SCIACT  program  developed  a  T&E  Management  Plan  that  identified  the  tests,  test  scheou’e 
test  organization  and  responsibilities,  test  personnel,  and  test  facilities.  The  plan  listed  these  tests: 

Environmental 

EMI 

EMP 

Tempest 

System  integration 
System  acceptance 

A  specific  test  plan  and  procedure  was  written  for  each  test.  The  test  personnel  participated  in  the 
development  of  these  documents  and  were  thoroughly  familiar  with  them  when  conducting  the  tests. 
The  program  was  completed  on  schedule  and  performed  satisfactorily  in  the  field.  Its  success  is  attributed 
to  good  planning,  competent  and  trained  personnel,  a  good  test  director,  and  sufficient  funding  to 
do  the  task. 

15.8.2  TRIDENT  Integrated  Radio  Room 

The  Integrated  Radio  Room  (IRR)  program  developed  the  external  communications  system  for 
the  TRIDENT  submarine.  This  project  also  developed  a  good  T&E  program.  This  was  a  dual 
development  FSP  program  from  which  a  production  contractor  was  to  be  selected,  after  Navy 
independent  testing  of  each  prototype.  Due  to  overruns  and  schedule  slippages,  the  dual  independent 
Navy  tests  were  not  conducted,  but  each  system  (neither  \  'as  completed)  was  simultaneously  tested 
at  each  contractor’s  facility,  with  the  help  of  the  particular  developing  contractor.  The  results  of  these 
tests,  plus  the  proposals  of  each  contractor  to  complete  their  system,  were  evaluated,  and  one  contractor 
was  selected  for  a  limited  production. 

The  first  unit  delivered  underwent  a  complete  independent  Navy  acceptance  and  TECHEVAL. 
Tests  were  conducted  on  this  system  for  more  than  1  year,  due  to  a  delay  in  hull  delivery.  These  tests 
caused  numerous  hardware  and  software  changes  to  be  made  to  the  system.  This  resulted  in  an  operational 
system  being  delivered  to  the  first  submarine. 

15.8.3  Message  Processing  and  Distribution  System  (MPDS) 

This  project  rushed  the  hardware  development  and  the  T&E  program.  The  operator  terminals  were 
advance  breadboard  models  that  were  installed  on  the  first  operational  platform.  Likewise,  the  Data 
Acquisition  and  Distribution  Unit  was  a  laboratory  model  that  was  integrated  into  the  first  deliverable 
system.  The  reliability  and  MTBF  was  very  poor  (we  are  talking  about  the  late  60s,  early  70s  when 
T&E  was  primarily  a  production  acceptance  test).  The  poor  reliability  created  much  user  dissatisfaction, 
which  was  not  easily  overcome. 
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SECTION  16 

TECHNICAL  INFORMATION  SUPPORT 


16.1  INTRODUCTION 

16.1.1  References 

DoD  Instruction  5200.21;  Dissemination  of  DoD  Technical  Information,  27  September  1979 
DoD  Directive  3200.12,  DoD  Scientific  and  Technical  Information  Program,  15  February  1983 
SECNAV  Instruction  3900.43,  Navy  Scientific  and  Technical  Information  Program,  29 
December  1983 

NAVMAT  Instruction  4160.2,  Technical  Manual  Management,  24  November  1980 

NAVSEA  Instruction  4160.3,  Technical  Manual  Management  Program  (TMMP).  August  1982 

NOSC  Instruction  4160.1  A,  Technical  Manual  Procedures,  1  November  1985 

NOSC  Instruction  5600.2D 

NOSC  Instruction  5400.2D 

NOSC  TD  178,  Revision  B 

NOSC  TD  611 

NOSC  TD  841,  Distribution  Statements  for  Technical  Publication? 

NOSCINST  5290.1,  Photographic,  Video  and  Audiovisual  Operations  and  Material  Control 
OPNAVINST  5290.1,  Navy  Audiovisual  Management  and  Operations  Manual 
NOSCINST  5070. IB,  NOSC  Library  Services,  19  November  1985 
NOSCINST  3900.2B,  Initiation  of  New  Technical  Work  Assignments;  Policies  and  Procedures 
for  6  April  1984 

NOSCINST  4200.5,  Procurement  Requirements  Package  (PRP)  Handbook,  30  August  1978 
Effective  Business  and  Technical  Presentations ,  by  George  L.  Morrisey 
How  to  Prepare,  Stage,  and  Deliver  Winning  Presentations ,  by  Thomas  Leech 

16.1.2  Summary 

Project  documentation  includes  requirements  for  the  publication  of  RDT&E  results  (in-house  and 
contract)  and  technical  manuals.  Various  DoD,  Navy,  and  NOSC  instructions  specify  requirements 
and  procedures  for  preparation,  production,  and  distribution  of  those  documents.  Lack  of  proper 
documentation  or  poorly  prepared  documentation  adversely  affects  both  DoD’s  RDT&E  program  and 
the  life  cycle  of  equipment  or  systems.  Project  managers  are  responsible  for  consulting  Code  961  at 
the  beginning  of  their  projects  to  ensure  proper  planning  and  adequate  funding  to  meet  the  specific 
requirements. 

Effective  visual  communcations  are  key  elements  in  project  management.  Photographic  and  video 
documentation  and  illustrations  of  experiments,  concepts  tests,  analysis  of  events,  and  ongoing  historical 
recordings  are  highly  visible  and  tangible  products  from  RDT&E  efforts.  A  visual  report  produced 
from  graphic  and  video  media  can  ensure  successful  competition  for  funds  and  the  imparting  of 
knowledge  and  information  in  the  most  direct  way.  Further,  the  costs  of  obtaining  the  visual  record 
are  more  than  offset  by  savings  of  valuable  scientific  and  engineering  manhours  that  would  otherwide 
be  devoted  to  reports  and  briefs. 
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NOSC  visual  media  specialists  are  dedicated  to  the  needs  of  the  RDT&E  programs  and  projects. 
As  part  of  the  RDT&E  team,  they  possess  the  unique  insight  to  capture  the  visual  record  in  the  most 
cost  effective  way  for  your  project. 

To  maximize  the  value  of  visual  documentation,  the  most  important  consideration  is  to  include 
visual  media  as  a  data  requirement  early  into  the  program.  This  will  ailow  for  funding  considerations 
of  these  requirements. 

The  Technical  Libraries  Branch  offers  a  full  range  of  library  services  as  detailed  in  NOSCINST 
5070.  IB.  Certain  aspects  of  these  services  are  particularly  important  to  the  project  manager  in  planning 
for  meeting  project  technical  information  needs. 

Finally  a  few  words  on  the  importance  of  presentations  complete  the  section. 


16.2  PUBL  ATION  REQUIREMENTS 

This  sect?  m  will  discuss  project  managers’  responsibilities  in  the  area  of  publications.  At  NOSC, 
technical  data  related  to  publications  are  divided  into  the  following  categories: 

Engineering  data  (e.g.,  logistic  support  plans,  safety  plans,  and  technical  manuals) 

Software  data  (e.g.,  manuals,  source  code,  and  supporting  documents) 

Research  and  development  data  (e.g.,  journal  articles  and  NOSC  technical  reports) 

The  information  presented  in  the  following  sections  is  generic  to  all  three  types  of  data.  However, 
because  of  the  stringent  and  complex  requirements  for  technical  manuals  (part  of  engineering  data), 
additional  information  on  procedures  and  requirements  for  manuals  has  been  included. 

16.2.1  General  Requirements 

16.2.1.1  DoD  Requirements.  DoD’s  Scientific  and  Technical  Information  Program  (STIP)  requires 
that  all  significant  results  derived  from  DoD  endeavors,  including  those  generated  under  contract,  be 
recorded  as  a  technical  publication  within  6  months  of  the  conclusion  of  the  work.  Both  positive  and 
negative  results  are  to  be  recorded.  These  publications  are  to  be  made  available  to  the  DoD  research 
and  engineering  community  through  the  Defense  Technical  Information  Center  (DTIC)  and  supporting 
libraries.  The  Program  also  requires  that  these  publications  be  prepared  according  to  established  standards 
for  format,  security  markings,  and  distribution  statements. 

16.2.1.2  NOSC  Requirements.  NOSC  instructions,  which  implement  DoD  requirements,  establish 
the  following  procedures: 

All  NOSC  Publications  intended  for  external  distribution  must  carry  a  NOSC  publication  number 
assigned  by  the  Publications  Branch.  (The  NOSC  publication  series  consists  of  technical  reports, 
technical  documents  (including  documentation  prepared  by  contractors],  technical  notes,  and 
technical  manuals.) 

These  publications  must  be  reviewed  by  branch  and  division  heads  for  technical  adequacy  and 
accuracy,  security  for  classification,  and  public  affairs  for  assignment  of  a  distribution  statement. 
(Although  all  publications  carry  distribution  statements,  only  unclassified  publications  are  reviewed 
by  the  public  affairs  office.) 
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The  publications  must  be  formal  rather  than  informal  publications.  The  distinction  between  formal 
and  informal  is  whether  the  publication  can  be  retrieved  from,  or  is  announced  in,  a  database 
accessible  to  DoD  employees.  Examples  include  the  Defense  Technical  Information  Center  and 
Navy  Publications  and  Forms  Center. 

The  publications  must  be  accurate,  comprehensible,  and  economically  produced.  Additionally, 
technical  manuals  must  be  available  to  meet  user  requirements  throughout  the  life  cycle  of  the 
equipment. 

Funding  for  publications  is  considered  an  integral  cost  of  the  project  and  must  be  provided  through 
project  funds.  For  technical  manuals,  the  cost  must  also  be  considered  a  part  of  the  overall  cost 
for  delivery  of  an  operational  system  or  piece  of  equipment. 

Technical  manual  specifications  must  be  tailored  to  allow  for  factors  such  as  user  profile, 
maintenance  plan,  and  training  requirements. 

Project  managers  often  establish  project  documentation  centers  to  produce  their  publications.  While 
there  is  no  problem  with  using  these  centers,  the  centers  must  operate  under  guidelines  established  by 
the  Publications  Branch.  When  you  are  ready  to  establish  such  a  center,  publications  personnel  will 
help  you  establish  procedures  specifically  suited  to  your  project. 

16.2.2  RESPONSIBILITIES 

16.2.2.1  Publications  Branch.  In  providing  documentation  services  to  project  managers,  the 
Publications  Branch  has  the  following  responsibilities: 

Coordinate  the  Center’s  publications  program  and  establish  policy  to  direct  that  program. 

Send  documentation  to  the  Defense  Technical  Information  Center  or  the  Navy  Publications  and 
Forms  Center. 

Provide  primary  and  secondary  distribution  of  NOSC  publications. 

Assign  all  formal  publication  numbers.  This  includes  assignment  of  technical  manual  identification 
numbers  required  and  controlled  by  systems  commands. 

Coordinate  all  technical  manual  efforts  (e.g.,  logistics  planning,  in-process  reviews,  acquisitions, 
validation,  verification,  and  changes). 


16.2.2.2  Project  Managers.  As  a  project  manager,  you  are  responsible  for  ensuring  that  publications 
are  an  integral  part  of  your  project  and  that  they  are  prepared  and  distributed.  Your  responsibilities 
include 

Coordinating  your  project’s  documentation  with  Publications  Branch  personnel 
Budgeting  and  funding  publications 

Ensuring  that  vour  contractors  are  aware  of  their  responsibilities 


16.2.3  Planning  for  Publications 

16.2.3.1  When  to  Start  Planning.  Planning  for  all  publications  must  begin  at  the  conceptual  phase 
of  a  project  and  continue  throughout  its  entire  life  cycle. 
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For  technical  manuals,  planning  should  also  occur  at  the  conceptual  phase  of  a  project  or,  at  the 
latest,  concurrently  with  performance  requirements. 

16.2.3.2  Types  of  Information  that  Should  be  Published.  Any  information  that  can  be  used  outside 
the  project  office  should  be  published  as  a  formal  NOSC  publication.  Generally  this  includes  the  following 
types  of  information: 

Information  that  contributes  to  increased  knowledge  of  natural  phenomena  and  the  environment; 
to  the  solution  of  problems  in  the  physical,  behavioral,  social,  and  management  sciences;  or  to 
the  expansion  of  knowledge  in  scientific  areas. 

Information  that  involves  the  extension  of  theoretical,  practical,  and  useful  applications  of  basic 
designs,  ideas,  and  scientific  concepts. 

Information  that  documents  the  procedures  and  results  of  subjecting  systems,  items,  materials, 
personnel,  or  techniques  to  simulated  or  actual  operational  conditions  to  determine  characteristics, 
suitability,  and  compliance  with  specific  requirements. 

Information  that  provides  values,  appraisals,  or  results  relevant  to  strengths,  weaknesses,  feasibility, 
potential,  and  military  worth  of  efforts,  concepts,  or  hardware. 

16.2.3.3  Cost  of  Publications.  For  all  publications  other  than  technical  manuals,  the  project  manager 
should  allow  5  to  10  percent  of  the  project  cost  for  documentation.  Allow  10  percent  if  you  plan  on 
having  someone  other  than  project  personnel  do  the  original  writing  and  research. 

For  technical  manuals,  allow  $300  to  $1000  per  page.  Specific  costs  for  a  project  can  be  obtained 
from  the  technical  manuals  personnel  in  the  Publications  Branch. 

16.2.3.4  Time  Required  for  Publications.  Production  of  a  publication  involves  five  basic  steps: 
writing,  editing,  production,  printing,  and  distribution.  All  these  steps  require  time  and  allocation  of 
personnel.  For  planning  purposes,  allow  8  to  10  weeks  for  preparation  of  a  formal  NOSC  publication, 
if  a  written  manuscript  is  provided  to  the  branch.  If  you  need  original  writing,  additional  time  must 
be  allowed;  the  time  is  dependent  upon  the  specific  task  involved.  When  a  copy  of  a  publication  is 
required  for  immediate  use,  arrangements  can  be  made  to  prepare  an  advance  copy  within  24  hours. 

For  technical  manuals,  time  must  also  be  allowed  for  logistics  certification,  which  is  dependent 
upon  availability  of  equipment  and  military  personnel,  and  for  specification  tailoring.  This  tailoring 
will  vary  for  each  project  and  will  depend  upon  factors  such  as  system  command  requirements,  users, 
and  planned  maintenance. 

16.2.4  Distribution  of  Publications 

16.2.4.1  Distribution  Statements.  All  publications  must  be  marked  with  a  distribution  statement. 
The  purpose  of  the  statement  is  to  control  the  secondary  distribution  of  the  publication.  Distribution 
statements  are  assigned  by  the  technical  codes  and  reviewed  by  security  and  public  affairs  offices.  NOSC 
forms  5605  and  5720  are  used  for  this  purpose. 

16.2.4.2  Inclusion  in  DoD  Databases.  All  NOSC  formal  publications,  with  the  exception  of  system- 
command-numbered  technical  manuals,  must  be  available  through  the  Defense  Technical  Information 
Center.  (Information  up  to  and  including  secret  is  sent  to  DTIC.)  If  the  information  in  the  publication 
is  so  sensitive  that  a  copy  cannot  be  provided  to  DTIC,  DTIC  must  be  given  a  bibliographic  citation 
that  announces  the  availability  of  the  publication.  At  NOSC,  the  Publications  Branch  does  this  by 
use  of  the  DID  Form  1473. 


Those  publications  that  are  specifically  related  to  subjects  such  as  chemical  propulsion,  tactical 
weapons  guidance  and  control,  infrared  technology,  plastics,  reliability,  and  shock  and  vibration  are 
also  sent  to  appropriate  information  analysis  centers.  These  centers  are  administratively  managed  and 
funded  by  the  Defense  Logistics  Agency. 

NOSC-numbered  technical  manuals  are  sent  to  DTIC.  They  can  be  provided  to  sponsors  and  used 
before  a  project  moves  to  milestone  II.  However,  they  cannot  be  sent  to  the  Navy  Publications  and 
Forms  Center  or  used  on  shipboard  except  during  the  experimental  phase  of  a  project.  Those  manuals 
with  system-command  numbers  are  distributed  to  the  Fleet  through  NPFC. 

16.2.5  Contracts  for  Publication  Services 

Contracting  is  usually  a  part  of  project  management  and  always  results  in  documentation.  When 
preparing  your  contract  package,  use  the  following  guidelines: 

Ensure  that  the  contractor  provides  documents  that  are  suitable  for  entry  into  DTIC.  This  means 
that  the  documents  must  be  complete,  legible,  reproducible,  technically  accurate,  and  sufficiently 
detailed  to  permit  use  of  the  publication. 

Use  data  item  descriptions  that  are  appropriate  to  the  type  of  documentation  being  ordered  (e.g., 
test  plans,  test  results,  research  reports).  The  data  management  office  can  provide  assistance  in 
that  area,  as  well  as  the  publications  personnel. 

All  publications  ordered  should  be  subject  to  preliminary  government  review  before  final  acceptance. 
During  this  review,  subject-matter  experts  outside  the  project  should  be  asked  to  review  the  data. 
This  allows  any  problems  to  be  identified  and  corrected  by  the  contractor. 

Technical  manuals  are  ordered  by  a  contract  exhibit  that  is  called  the  technical  manual  contract 
requirement.  This  is  a  requirement  for  hardware  manuals  and  an  option  for  software  manuals. 
Data  item  descriptions  can  no  longer  be  used  to  order  hardware  technical  manuals. 

Data  item  descriptions  are  used  to  order  such  technical  manual  data  as  outlines  and  book  plans. 

Include  electronic  data  as  the  original  copy.  This  will  allow  the  Publications  Branch  to  save  your 
original  text  and  artwork. 

16.2.6  Types  of  Publications 

16.2.6.1  Technical  Report.  Definition:  Presents  results  of  an  effort  undertaken  by  NOSC  toward 
an  objective  defined  by  a  sponsor.  May  be  a  final,  summary,  or  progress  report.  Subject  matter  usually 
categorized  as  RDT&E.  Has  specific  format  and  content  requirements.  Is  a  formal.  Center-approved 
publication. 

Review  and  Release:  All  carry  a  formal  distribution  statement  ( A  through  F  or  X).  All  reviewed 
by  branch  and  division  heads,  security,  and,  if  unclassified,  by  PAO. 

Distribution:  Provided  to  DTIC  (for  sensitive  information,  only  a  DD  Form  1473  is  provided), 
sponsor,  and  NOSC.  Additional  distribution  depends  upon  distribution  statement  and  author’s  requests. 

16.2.6.2  Technical  Document.  Definition:  Covers  class  of  publications  not  considered  as  reports 
(i.e ,  they  do  not  report  the  results  of  a  specific  scientific  or  engineering  effort).  Subject  matter  usually 
categorized  as  software,  engineering,  or  administrative.  Includes  publications  such  as  proposals,  reliability 
plans,  safety  plans,  viewgraph  compilations,  conference  proceedings,  computer  programs,  engineering 
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change  proposals,  and  specifications.  No  specific  format  or  content  requirements.  Is  a  formal,  Center-  «#jjV 
approved  publication.  xw> 

Review  and  Release:  All  carry  a  formal  distribution  statement  (. A  through  For  X).  All  are  reviewed 
by  branch  and  division  heads,  security,  and,  if  unclassified,  by  PAO. 

Distribution:  Provided  to  DTIC  (for  sensitive  information, -only  a  DD  Form  1473  is  provided), 
sponsor,  NOSC,  and  appropriate  DoD  information  analysis  centers.  Additional  distribution  depends 
upon  distribution  statement  and  author’s  requests. 

16.2.6.3  Technical  Manual.  Definition:  Describes  specific  equipment,  weapon,  or  system  and  provides 
instructions  for  installation,  operation,  maintenance,  overhaul,  and/or  personnel  training.  Includes 
both  hardware  and  software.  Has  specific  format  and  content  requirements.  Is  a  formal.  Center-approved 
publication. 

Category  I  manuals  are  prepared  prior  to  milestone  II.  are  prepared  in  support  of  R&D  equipment 
and  systems,  and  are  used  for  computer  software  manuals. 

Category  II  manuals  are  developed  for  Fleet  use. 

Review  and  Release:  All  carry  a  formal  distribution  statement  ( A  through  For  X).  All  are  reviewed 
by  branch  and  division  heads,  security,  and,  if  unclassified,  by  PAO. 

Distribution:  Provided  to  sponsor  and  NOSC  (system  command  manuals  are  also  sent  to  NPFC). 
Additional  distribution  depends  upon  distribution  statement  and  author’s  requests. 


16.2.6.4  Technical  Note.  Definition:  Contains  informal  or  transitory  information.  Is  considered  a 
working  paper.  No  specific  format  or  content  requirements.  Is  an  informal  paper  that  does  not  represent 
NOSC  policy. 

Review  and  Release:  All  carry  a  disclaimer  that  designates  them  as  working  papers.  Cannot  be 
assigned  a  formal  distribution  statement.  All  are  reviewed  by  branch  and  division  heads,  security,  and, 
if  unclassified,  by  PAO. 

Distribution:  Provided  only  to  sponsor  and  NOSC.  No  distribution  to  DoD  databases. 


16.3  VISUAL  MEDIA 

The  intent  of  this  subsection  is  to  outline  the  visual  media  services  available  and  how  you  may 
obtain  them  for  your  project  support. 


16.3.1  4udiovisual  (Visual  Media)  Definitions 

The  following  definitions  are  extracted  from  NOSCINST  5290.1,  Photographic,  Video  and 
Audiovisual  Operations  and  Material  Control.  These  terms  provide  a  common  basis  for  the  elements 
of  audiovisual  systems. 


16.3.1.1  Audiovisual  (AV)  Visual  Media.  The  use  of  sound  or  visual  imagery  or  both  to  communicate 
information.  The  definition  includes  use  of  motion  pictures,  video,  still  photographs,  slides  and  film¬ 
strips,  audio,  graphic  illustrations,  models,  and  displays.  (Visual  Media  is  basically  the  same  as 
audiovisual.) 
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16.3.1.2  Audiovisual  Activity.  An  organizational  element  or  a  function  within  an  organization  in 
which  one  or  more  individuals  are  classified  as  audiovisual  or  whose  principal  activity  is  to  provide 
AV  services  and  products  or  to  manage  AV  resources.  The  term  applies  but  is  not  limited  to  AV 
equipment,  facilities,  products,  personnel,  maintenance,  supplies,  procurement,  and  budget. 


16.3.1.3  Audiovisual  Equipment. 

a.  Items  of  a  durable  nature  that  are  capable  of  continuing  or  repetitive  use  by  an  individual 
oi  organization  for  recording,  production,  reproduction  processing,  and  exhibiting  AV  products 
or  documentation.  (Included  are  photographic,  television,  videotape  or  videodisc,  audiotape 
or  audiodisc,  graphic  arts  and  computer  graphics  equipment.) 

b.  Items  that  have  an  AV  function  as  an  integral  part  of  a  non-AV  system  or  device  (existing 
or  under  development)  and  that,  when  permanently  removed,  can  be  identified  as  an  end- 
item  of  equipment. 

16.3.1.4  Audiovisual  Product.  Audiovisual  media  elements  such  as  still  photography,  graphic  arts, 
still  projections  (overhead  transparencies,  slides,  and  filmstrips),  motion  pictures  (film,  videotape, 
and  videodisc)  and  audio  recordings  (tape  and  disc).  Production  is  a  unique  form  of  AV  product  and 
is  usually  addressed  separately. 

16.3.1.5  Audiovisual  Production.  A  unified  presentation  that  contains  sound  or  visual  imagery  or 
both;  is  titled,  edited,  and/or  accompanied  by  sound;  and  conveys  a  message  through  a  recorded  medium 
or  broadcast.  The  term  may  also  apply  to  combining  or  arranging  any  separate  or  combined  audio 
or  visual  product(s)  in  continuity  according  to  a  plan  or  script.  A  production  is  the  end-item  of  the 
production  process.  This  term  is  synonymous  with  the  Office  of  Management  and  Budget  (OMB)  use 
of  the  term  “audiovisual  product.” 

16.3.1.6  Authorized  Photographer/Recorder.  An  employee  who  occasionally  needs  to  use  a  camera, 
video,  or  sound  recorder.  The  Camera/ Video/Recording  (CVR)  Equipment  Pass  (form  NOSC-SD 
5512/21)  is  issued  to  these  persons  for  a  period  not  to  exceed  12  months. 

16.3.1.7  Computer-Generated  Graphics  System.  An  integrated  computer,  minicomputer,  or 
microcomputer  and  software  system  designed  and  intended  primarily  for  generation  of  graphic  arts 
productions;  or  a  system  composed  of  selected  computer,  minicomputer,  or  microcomputer  hardware 
components,  plotters,  and  software  systems  whose  primary  purpose  is  to  produce  graphic  arts  displays, 
charts,  and  pictures. 

16.3.1.8  Dedicated  AV  Support  Activity  (DAVSa).  An  AV  activity  that  provides  dedicated 
audiovisual  support  which  is  integral  to  the  performance  of  the  primary  mission(s)  of  the  Center.  It 
does  not  include  productions,  production  services,  and  related  support  functions. 

16.3.1.9  Graphic  Arts.  Relates  to  the  design,  creation,  and  preparation  of  two-  and  three-dimensional 
visual-aid  products.  The  definition  includes  charts;  graphs,  posters;  visual  materials  for  television,  motion 
pictures,  and  publications;  displays  and  presentations;  and  exhibits  prepared  manually,  by  machine, 
or  by  computer. 

16.3.10  Major  Claimant.  An  organization  directly  subordinate  *  >,  established  by  authority  of,  and 
specifically  designated  by  the  Secretary  of  the  Navy.  (NOSC’s  majv.'  claimant  is  the  Space  and  Naval 
Warfare  Systems  Command,  Code  512.) 
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16.3.1.11  Official  Navy  Photography.  Those  functions  that  are  concerned  with  aerial,  surface,  and 
underwater  still,  motion  picture,  audio,  and  video  documentation  necessary  to  support  the  Naval 
establishment.  For  this  instruction,  “Official  Navy  Photography”  includes  still,  motion  picture, 
photographic  instrumentation,  and  audio  and  video  documentation,  along  with  the  film,  prints,  and 
tapes  produced  at  Government  expense  by  Government  employees  or  by  contract  for  the  Government. 

16.3.1.12  Official  Photographer.  An  individual  whose  sole  employment  is  making  official 
photographs,  motion  pictures,  video  recordings,  or  production  of  RDT&E  products  and  audiovisual 
presentations  developed  from  these  products.  An  official  Photographer’s  Pass  is  issued  only  to  such 
individuals. 

16.3.1.13  Optical  Instrumentation.  Use  of  optical  systems,  coupled  with  photographs  or  television 
recording  devices,  which  may  include  audio,  to  record  scientific  and  engineering  phenomena  for 
measurement  and  analysis.  The  definition  may  include  the  recording  of  data  to  correlate  optical  images 
to  time,  space  positions,  or  other  engineering  data. 

16.3.1.14  Technical  Documentation.  Audiovisual  resources  dedicated  to  documentation  of  technical 
subjects  for  the  purpose  of  supporting  the  RDT&E  mission.  This  includes  resources  defined  previously 
as  “Official  Navy  Photography”  as  well  as  film  and  video  reports  of  a  basic  nature  (recorded  narration 
and  approved  titles),  slide  and  audio  presentations,  graphic  arts  training  aids  and  devices,  and  audiovisual 
design  subfunctions  where  the  purpose  is  to  record,  propose,  report,  or  convey  technical  data  on  RDT&E 
programs.  Technical  documentation  for  RDT&E  is  exempted  from  the  controls  established  for 
audiovisual  products  for  training  and  information  purposes. 

16.3.1.15  Technical  Report.  An  AV  report.  An  assemblage  of  film  or  video  clips.  An  assembly  of 
technical  documentation  to  report  on  a  single,  mission-related  event. 

16.3.2  Visual  Documentation 

WUhin  a  given  program  or  project,  virtually  every  event  and  milestone  that  make  up  the  system’s 
life  span  can  benefit  from  visual  documentation.  Certain  media  are  more  suited  for  given  events  or 
milestones  in  the  RDT&E  process  depending  upon  the  requirement. 

The  following  outline  is  an  example  of  milestones  and  visual  media  products/documentation  that 
would  apply  at  those  designated  times. 


Milestone 

Purpose 

Products 

a. 

Identify/Define 

Briefing/Proposals 

Viewgraphs,  Slides 

Requirement 

Displays,  Illustrations 

b. 

Submit  Proposals/ 
Obtain  Funding 

Briefing/Presentations 

Viewgraphs,  Slides 

c. 

Research 

Document/Record  Data 

Still  Photography 

Use  in  Reports 

Viewgraphs,  Slides 
Illustrations 

d.  Development 


Document/Record  Data 
Use  in  Reports 


Motion  Pictures,  Still 
Photos,  Videofilm 


e.  Testing/Evaluation  Document/ Record  Data  Motion  Pictures,  Still 

Use  in  Reports  Photos,  Videofilm 

f.  Modifications/  Document/Record  Data  Motion  Pictures,  Still 

Follow-On  OT&E  Use  in  Reports  Photos,  Videofilm 

g.  Project  Completion  Final  Report/Historical  Videofilm,  Viewgraphs 

Report  Slides 

While  there  are  no  established  criteria  for  visual  documentation,  this  outline  cites  several  areas  to  consider. 
The  value  of  visual  records  to  RDT&E  programs  has  been  demonstrated  countless  times. 

16.3.3  Visual  Media  Products  and  Services 

The  following  visual  media  products  and  services  are  available  through  Code  962,  the  Visual  Media 
Branch,  Technical  Information  Division. 

16.3.3.1  Graphics.  Illustrations  ranging  from  sketch  to  3-D  technical,  architectural  renderings,  design, 
phototypesetting,  and  computer  graphics  are  available.  Uses  include  motion  and  still  photo,  video 
presentations  and  briefs,  brochures,  programs  and  flyers,  signs,  exhibits  and  displays,  awards,  and 
special  applications. 

16.3.3.2  Still  Photography.  Services  include  all  black  and  white  and  color  processes,  both  large  and 
small  parts/systems  illustrations,  oversize  black  and  white  copy  photography  for  electromechanical 
and  other  high-resolution  schematics,  technical  and  engineering  underwater  applications,  optical 
instrumentation,  and  portraiture. 

16.3.3.3  Television  and  Motion  Pictures.  Products  and  services  range  from  one-time  documentation 
of  an  event  or  test  to  a  complete  presentation  using  all  visual  media  elements  from  script  to  narration. 
Color  or  black  and  white  video  or  motion  photography  is  available  depending  upon  the  requirement. 
Full  postproduction  services  are  offered  including  a  studio,  sound  recording,  editing,  special  effects, 
and  other  electronic  features.  A  classified,  Tempest-certified  video  editing  system  is  also  available  for 
confidential  and  secret  materials.  Special  applications  for  underwater  video  and  film  coverages  are 
also  available. 

16.3.3.4  Presentations.  The  Visual  Media  Branch  can  create  and  assemble  a  media  package  for 
presentation  by  yourself  or  as  a  self-contained  program  for  distribution  to  other  activities. 

16.3.3.5  Audiovisual  Equipment  Loan  Pool.  This  service  is  available  to  all  Center  personnel.  The 
loan  pool  was  established  as  a  source  for  common  type»  of  AV  equipment  and  accessories  that  are 
needed  for  short-term  loans.  Included  are  slide  and  motion  picture  projectors,  video  recorder  playback 
units,  VHS  self-contained  video  camcorders,  still  picture  cameras,  and  associated  accessories. 

16.3.4  Guidelines  for  Vie*vgraphs 

Viewgraphs  are  the  principal  media  used  at  NOSC  for  briefings  and  presentations.  However,  35mm 
slides  can  be  produced  from  the  same  artwork,  if  required. 


The  Visual  Media  and  Publications  Branches  of  Technical  Information,  working  in  concert,  provide 
complete  services  from  layout  and  design  to  editorial  review.  All  viewgraphs  are  edited,  then  proofread 
after  completion.  TID’s  responsibility  is  to  ensure  all  viewgraphs  convey  the  information  while 
representing  NOSC  in  the  most  favorable  way. 

16.3.4. 1  The  Guidelines.  The  following  viewgraph  preparation  guidelines  will  help  ensure  a  measure 
of  consistency  between  various  NOSC  presentations  and,  at  the  same  time,  give  your  presentations 
a  more  professional  look.  Figures  16.1  through  16.4  are  sample  viewgraph  formats. 

First,  always  remember  your  audience!  The  basic  requirement  for  a  viewgraph  is  :hat  it  be 
READABLE  by  everyone  in  the  audience.  To  meet  this  requirement,  the  message  on  the  screen  should 
be  conveyed  simply  and  quickly. 

Second,  work  toward  the  fewest  and  shortest  words  possible.  The  fewer  words  on  your  visual  the 
better  your  idea  will  be  understood.  Some  ways  to  get  concise,  clear  visuals  are  listed  here: 

a.  Cut  all  unnecessary  qualifiers  (words  or  phrases  that  modify,  limit,  or  qualify  other  words  or 
phrases).  Well-done  viewgraphs  have  NO  qualifiers— the  speaker  provides  them. 

b.  Cut  down  on  connectives  (and,  or,  for,  but,  yet,  &  nor).  Instead,  commas  and  ampersands 
(&)  can  be  used  in  visuals  to  cut  down  on  words. 

c.  Limit  your  total  word  count  to  50  or  less.  This  doesn’t  include  the  title.  Remember,  however, 
to  keep  your  titles  short  and  meaningful.  Long,  rambling  titles  tend  to  introduce  long,  rambling 
messages. 

d.  Break  your  viewgraph  into  sections.  If  your  message  must  exceed  50  words,  put  each  section 
on  a  new  viewgraph.  Two  well-done  viewgraphs  are  always  more  understandable  than  one  that 
is  crowded  and  verbose. 

e.  Limit  the  number  of  diagrams  or  pictures.  If  you  have  a  specific  diagram  or  illustration  as  well 
as  some  text  or  narrative,  limit  the  viewgraph  to  one  picture  or  diagram.  There  is  a  natural 
tendency  at  times  (to  cover  the  whole  story)  to  place  a  diagram,  a  photo,  a  milestone  chart, 
and  narrative  all  in  one  viewgraph  (essentially,  it  is  four  separate  viewgraphs  in  one).  This  may 
be  fine  for  a  handout,  but  for  a  visual  on  a  screen,  it  causes  confusion.  (The  result  is  usually 
worse  than  a  visual  with  too  many  words.) 

Following  the  above  guidelines  will  help  you  present  the  NOSC  story  in  the  most  favorable  light. 
In  addition  to  those  steps  mentioned  above,  the  graphics  section  uses  the  following  rules  when  preparing 
your  viewgraphs  for  Center-approved  presentations. 

a.  All  viewgraphs  have  a  red  title,  black  text,  and  a  clear  background. 

b.  Diagrams  and  graphs  use  blue  lines. 

c.  The  NOSC  logo  appears  in  the  upper  left  of  the  image  area. 

16.3.4.2  Scheduling.  To  ensure  a  quality  product,  the  graphics  section  needs  at  least  5  working  days 
from  date  received  in  graphics  to  date  delivered  back  to  you.  This  gives  us  enough  time  not  only  to 
edit  your  rough  copy,  but  also  to  proof  the  prepared  viewgraphs  and  correct  mistakes.  Rush  jobs  are 
sometimes  unavoidable,  but  editing  and  proofing  are  the  items  we  cut  when  you  need  a  job  quickly. 
Try  to  plan  your  presentations  with  enough  lead  time  to  let  us  give  you  the  best  product. 
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Figure  16.1.  Viewgraph  sample  1. 
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Figure  16.2.  Viewgraph  sample  2. 
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Figure  16.3.  Viewgraph  sample  3, 
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16.3.5  Planning  Considerations  for  Visual  Media 

Just  as  time  itself  is  transient  and  cannot  be  recaptured,  so  is  the  chance  for  visual  documentation 
of  a  given  event.  The  historical  record  is  lost,  unless  it  is  captured  on  film  or  video.  The  visual  records 
of  World  War  II  and  other  modern  conflicts  have  proven  the  immeasurable  value  of  photographic 
documentation. 

The  Technical  Information  Division  (TID)  exists  to  provide  products  and  services  to  the  Center 
and  specifically  to  program  managers.  The  Visual  Media  Branch  of  TID  can  best  serve  programs  and 
projects  by  providing  documentation  of  key  events  and  milestones.  The  milestone  examples  listed 
previously  under  Visual  Documentation  (16.3.2)  should  all  be  considered  when  your  total  requirements 
for  the  project  are  defined. 

Bring  the  visual  media  staff  into  the  planning  process.  This  will  ensure  that  adequate  coverage 
of  significant  events  is  included  in  your  project  documentation. 

Contact  the  applicable  visual  media  staff  person  or  section  for  assistance  on  all  proposals. 


16.3.6  Contacts  for  Assistance 


Management 

Ken  Callahan 

x34826 

Visual  Info  Consultants 

A1  Woerner 

X34828 

Graphics 

George  Galaich 

x34832 

Still  Photography 

Jim  Corbin 

x34850 

Television/Motion  Pictures 

Stan  Follis 

x34869 

Photo  Officer  (Code  9603) 

Roy  George 

x34788 

AV  Equipment  Loan  Pool 

Ernie  Santos 

X35233 

16.4  TECHNICAL  LIBRARY  SERVICES 
16.4.1  Library  Collections 

There  are  three  locations  of  the  NOSC  Technical  Library:  Topside,  Bayside,  and  Hawaii.  Materials 
are  collected  in  disciplines  and  subject  areas  pertinent  to  the  current  NOSC  mission.  Materials  are  located 
in  the  Bayside  and  Topside  Libraries  according  to  the  location  of  scientists  and  engineers  specifically 
working  in  disciplines  or  subject  areas.  For  example,  underwater  ordnance,  underwater  engineering, 
and  marine  chemistry  materials  are  found  primarily  in  the  Bayside  Library,  while  communications  and 
artificial  intelligence  materials  are  in  the  Topside  Library. 

The  Library  holds  all  major  reference  works,  indexes,  and  abstracts  in  the  physical  sciences, 
engineering,  and  life  sciences  pertinent  to  the  NOSC  mission.  Special  resources  include  an  extensive 
collection  of  maps  and  charts  located  in  the  Topside  Library  and  staffed  by  a  professional  map  librarian, 
and  a  collection  of  technical  reports  on  artificial  intelligence  from  the  major  universities  working  in 
this  area,  such  as  MIT,  SRI,  and  others.  The  Bayside,  Topside,  and  Hawaii  Libraries  each  house  a 
complete  and  current  collection  of  all  military  and  federal  specifications,  standards,  handbooks,  and 
drawings. 
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16.4.2  Acquisitions  Policy 


New  titles  are  selected  for  purchase  by  NOSC  librarians  (frequently  in  advance  of  publication) 
and  also  by  Library  users.  The  Library’s  overhead  funds  are  used  for  most  book  purchases,  although 
funding  is  requested  from  users  for  unusually  expensive  titles  or  desk  copies.  Codes  are  requested  to 
fund  all  of  their  periodical  subscription  requirements,  although  the  Library  will  place  the  orders  and 
provide  receipt  control. 

Program  managers  should  attempt  to  anticipate  their  need  for  both  specific  publications  and  subject 
coverage  by  consulting  with  NOSC  librarians.  Acquisition  of  publications  can  be  a  lengthy  process. 

The  Library  is  the  internal  approval  control  point  for  all  Center  purchases  of  books,  publications, 
maps,  specifications,  subscriptions,  bibliographic  retrieval  systems,  etc.  The  Library  will  determine 
the  most  expeditious  means  of  acquisition,  and  in  most  cases,  will  handle  purchase  of  publications 
intended  for  exclusive  use  by  a  project  office.  Such  publications  will  be  cataloged  in  the  Library’s  system 
but  will  also  be  identified  as  in  use  for  an  indefinite  period  by  the  requester. 

Publications  ithat  are  not  available  for  purchase  may  usually  be  borrowed  from  other  libraries 
or  photocopied.  The  NOSC  Library  borrows  not  only  from  local  libraries,  but  also  from  Department 
of  Defense,  corporate,  public,  and  university  libraries  throughout  the  United  States  and  Great  Britain. 

16.4.3  Library  Access 

The  Library  is  accessible  by  all  NOSC  employees  and  also  NOSC  contractors.  Materials  may  be 
borrowed  only  by  NOSC  employees.  NOSC  contractors  may  use  materials  on  hand;  materials  in  use 
will  not  be  recalled  for  them. 

Program  managers  should  discuss  the  technical  information  requirements  of  their  contractors  with 
the  NOSC  librarian  for  the  purpose  of  planning  appropriate  Library  access  and  services.  Contractor 
access  to  the  Library’s  technical  report  collection  must  be  on  a  need-to-know  basis.  Procedures  are 
detailed  in  NOSCINST  5070. IB,  paragraph  5. 

16.4.4  Reference/Literature  Search  Services 

The  Library  offers  reference  service  by  professional  librarians  ranging  from  locating  specific 
handbook-type  information  to  compiling  comprehensive  subject  bibliographies.  Online  access  is 
maintained  to  all  available  commercial  and  government  databases  pertinent  to  NOSC’s  areas  of  interest. 
Librarians  search  these  databases  at  no  charge  to  Library  users. 

The  Library  maintains  secure  online  links  to  the  databases  of  the  Defense  Technical  Information 
Center  (DTIC).  NOSC  scientists  and  engineers  are  required  to  request  searches  of  the  DTIC  databases 
when  beginning  new  projects  (in  accordance  with  DoD,  Navy,  and  NOSC  instructions  for  the  purpose 
of  verifying  that  their  projects  are  not  duplicating  other  efforts). 

16.4.5  Library  Publications 

The  Library  disseminates  a  list  of  its  periodical  holdings,  a  periodic  (usually  every  3  to  4  weeks) 
list  of  new  publications  acquired,  and  various  current  awareness  listings.  Customized  current  awareness 
listings  may  be  requested  to  cover  specific  project  interests  at  no  cost  to  the  requester. 
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16.4.6  Special  Projects  and  Services 

The  Library  staff  is  currently  in  the  final  stages  of  implementing  an  integrated  online  library  system 
called  DATALIB.  Eventually  all  Library  holdings  will  be  retrievable  from  an  online  catalog.  The  catalog 
is  now  available  for  use  in  any  of  the  libraries  and  will  become  available  via  the  GCB  sometime  in 
1988.  More  information  about  the  system  is  found  on  the  next  "age. 

The  Library  has  established  a  database  of  the  databases  or  project  libraries  located  outside  the 
Technical  Libraries.  This  Database  of  NOSC  Databases  is  included  in  the  Library’s  online  catalog. 
Employees  are  requested  to  register  descriptive  information  about  their  project  databases  with  the  NOSC 
librarian. 

The  Library  offers  a  consultation  service  for  project  managers  with  a  requirement  tor  carting 
a  new  database.  The  Library  will  advise  on  organization,  cataloging,  and  indexing  of  materials  and 
will  also  provide  guidance  in  selection  of  software  for  storage  and  retrieval.  The  Library  holds  several 
such  software  and/or  demonstration  packages  for  review  by  project  managers. 

Program  managers  may  request  Library  support  for  contractor  review  of  documentation.  The 
Library  will  provide  storage,  retrieval,  and  access  control  of  project  documents  during  the  proposal 
period. 

Several  presentations  on  Library  services  are  offered.  There  is  a  tour  of  the  Library  every  work 
Friday  at  0900  at  the  Topside  Library;  no  appointment  is  necessary.  Project  managers  may  request 
a  more  formal  presentation  describing  Library  services  and  also  a  presentation  on  the  Library’s  various 
online  database  resources.  Soon  to  be  available  is  a  presentation  on  map  and  chart  resources. 

Finally,  Tables  16.1  through  16.5  present  further  specific  information  on  Library  contacts,  online 
retrieval  systems,  SDI  services,  the  DATALIB  system,  and  map  resources.  The  NOSC  Library  request 
for  literature  search  form  is  shown  in  Figure  16.5. 
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DATALIB 


DATAL1B  is  the  Technical  Library’s  integrated  online  library  system.  It  has  been  installed  on 
a  VAX-750,  formerly  the  EEL  and  now  renamed  the  SNOOK.  The  DATALIB  system  consists  of  four 
functional  modules:  bibliographic,  circulation,  acquisitions,  and  serials  control.  The  Library  staff  is 
currently  working  on  implementation  of  the  bibliographic  function,  which  is  actually  the  online  catalog 
of  all  the  Library’s  holdings  and  also  serves  as  the  master  record  for  the  other  three  modules. 

DATALIB  is  a  powerful  retrieval  system  specifically  developed  for  technical  libraries.  Some  of 
the  other  users  of  the  system  are  the  General  Motors  Research  Labs.,  Martin  Marietta,  RCA,  Kerr- 
McGee,  Schlumberger,  Texaco,  Air  Products,  Merck,  and  the  Department  of  Justice.  The  vendor  is 
Sigma  Data  Services. 

Some  major  capabilities  of  DATALIB  are 

•  online  catalogs  (ours  will  eventually  include  all  the  Library’s  holdings  of  books,  technical  reports, 
periodicals,  papers  by  NOSC  authors,  maps,  charts,  trade  catalogs,  phone  books,  patents, 
standards,  audiovisual  materials,  software,  and  pamphlets) 

•  retrieval  by  either  menu  or  command-level  searching  using  Boolean  connectors 

•  online  circulation  of  Library  materials  using  bar  codes 

•  circulation  status  displayed  for  items  retrieved  (i.e.,  Is  an  item  on  the  shelf?) 

•  online  record  of  items  on  order  and  their  status 

•  online  check-in  and  records  of  periodical  issues 

•  capability  for  the  Library  to  host  multiple  databases 

Concurrent  with  implementing  the  DATALIB  bibliographic  function  is  the  Library’s  RECON  (or 
retrospective  conversion)  project.  This  entails  converting  all  of  our  old  records  to  machine  readable 
form  and  to  the  DATALIB  formats  we  designed,  and  also  bar  coding  all  materials. 

The  Library  closed  its  card  catalog  for  books  in  March  1987.  All  new  titles  are  in  the  online  catalog. 
The  technical  report  holdings  are  also  searchable  online.  The  target  date  for  availability  of  the  online 
catalog  on  the  GCB  is  February  1988.  We  anticipate  that  the  circulation  module  will  be  fully  implemented 
by  June  1988. 


Table  16.1.  Who  to  contact  in  the  NOSC  Libraries. 


HEAD  LIBRARIAN 

Joan  Buntzen 

X34879 

TOPSIDE  LIBRARY 

Reference/Literature  Searches/ 

Ordering 

Jo  Wa?sh 

Marcia  Whipple 

X34890 

X34888 

Circulation 

Jan  Ruiledge 

Janis  Anderson 

x34894 

X34893 

Maps/Charts/Specs  and  Standards 

Val  Danesh 

X34891 

Periodicals 

Jeanie  Casto 

X34881 

BAYSIDE  LIBRARY 

Supervisor 

Kathy  Wright 

X34900 

Reference/Literature  Searches/ 

T  ranslations/Ordering 

Diane  Soblick 
Helen  Cook 

X34902 

X34902 

Circulation 

Bernice  Kuntz 

X34908 

Interlibrary  Loans 

Yoli  Kerr 

x349C4 

NOSC  DATABASE  OF  DATABASES 

Kathy  Wright 

X34900 

LIBRARY  CONSULTING  SERVICE  FOR 

DATABASES 

Kathy  Wright 

x34900 

HAWAII  LIBRARY 

All  Services 

Pat  Kaneshiro 

x5247 

Technical  Library  Liaison 

Kathy  Wright 

X34900 

SEASIDE  LIBRARY  SERVICE 

Helen  Cook 

X34902 

ELECTRONIC  MAIL  ADDRESSES 

Topside  Library 

Bayside  Library 

Computer  Documents 

TOPLIB 

BAYLIB 

DOCUMENTS 

Table  16.2.  Online  information  retrieval  systems  accessible  by  the  NOSC  Technical  Libraries. 


DATALIB 

DATALIB  is  the  automated  library  system  that  provides  online  access  to  the  Libraries’  catalog  of  books, 
technical  reports,  periodicals,  and  other  publications.  Eventually  all  of  the  older  records  will  be  included 
in  the  online  catalog  and  access  will  be  made  available  to  NOSC  employees  via  the  GCB. 

DTIC  DROLS 

The  Defense  RDT&E  On-Line  System  (DROLS),  produced  by  the  Defense  Technical  Information  Center, 
provides  classified  (through  secret)  access  to  past,  current,  and  planned  work  sponsored  by  the 
Department  of  Defense.  DROLS  consists  of  three  databases:  Technical  Reports,  Work  Units  (1498s), 
and  industrial  Independent  Research  and  Development  Summaries. 

NASA/RECON 

Provides  access  to  more  than  2  million  technical  reports,  journal  articles,  books,  conference  proceedings, 
and  other  publications  in  the  fields  of  aerospace  and  related  technologies. 

DIALOG 

Provides  access  to  more  than  250  databases  in  all  subject  fields.  Many  of  these  databases  correspond 
to  printed  index  equivalents,  including  COMPENDEX  (Engineering  Index),  CA  SEARCH  ( Chemical 
Abstracts),  SCISEARCH  ( Science  Citation  Index),  INSPEC  (Physics  Abstracts,  Electrical  and  Electronics 
Abstracts,  Computer  and  Control  Abstracts),  and  NTIS  (National  Technical  Information  Service). 

ORBIT 

Provides  access  to  more  than  70  databases,  including  COLD,  a  database  of  technical  reports,  conference 
papers,  articles,  and  books  compiled  and  maintained  by  the  Army  Cold  Regions  Research  and  Engineering 
Laboratory. 

BRS 

Provides  access  to  more  than  70  databases,  including  RBOT,  a  database  on  robotics,  and  TECHDATA, 
an  online  index  to  specifications,  standards,  and  manufacturing  catalog  information. 

WILSONLINE 

Provides  access  to  general  indexes  such  as  Applied  Science  &  Technology  Index,  Business  Periodicals 
Index,  and  Readers  Guide  to  Periodical  Literature. 

OCLC 

An  online  union  catalog  of  over  14  million  books,  serials,  and  maps  owned  by  3600  member  libraries. 

USNI  MILITARY  DATABASE 

A  database  produced  by  the  United  States  Naval  Institute  that  provides  access  to  unclassified  information 
on  the  world’s  armed  forces,  their  organization,  orders  of  battle,  and  weapons. 

CORPTECH 

A  microcomputer  database  containing  information  on  developers  and  manufacturers  of  high  technology 
products  in  the  United  States,  (available  only  at  the  Topside  Library) 
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Table  16.3. 


Map  resources  at  the  NOSC  Technical  Libraries. 


TYPES  OF  MAPS/CHARTS  AVAILABLE: 

—  Hydrographic 

World  coverage  (DMA  Charts) 

U.S.  coastal  coverage  (NOAA  Charts) 

—  Topographic  (USGS  Maps) 

U.S.  series  —  scales  1:1,000,000  and  1:250,000 

States’  series  —  scales  1:62,500  (15  min.)  and  1:24,000  (7.5  min.) 

—  Bathymetric  (NOAA/USGS  Maps) 

—  Aeronautical  (DMA/NOAA  Charts) 

—  Road  maps  (Reference  only) 

—  Political  maps  (CIA  and  other  sources) 

—  General  world  and  U.S.  maps  (DMA  and  USGS  Maps) 

NAVIGATIONAL  AIDS 

—  Sailing  directions 

—  Coastal  pilots  and  fleet  guides 

—  Fog  and  light  lists 

—  Tide  tables 

—  Almanacs 

—  Booklets  on  chart/map  symbols,  abbreviations  and  terminology 

ATLASES 

—  General 

—  Specialized:  oceanographic,  climatological,  political,  etc. 

TO  OBTAIN  THESE  MATERIALS  OR  FOR  FURTHER  INFORMATION  CONTACT:  V.il  Danesh, 
Topside  Library,  Code  964 IT,  x34891. 
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Table  16.4.  Current  awareness  services  offered  by  NOSC  Technical  Libraries. 


Publications  that  provide  periodic  notification  of  new  publications  in  the  following  broad  subject  areas 
are  available  through  the  NOSC  Library.  To  be  placed  on  the  distribution  list  for  any  of  these  topics, 
contact  Jan  Rutledge  at  x34894.  To  request  that  a  current  awareness  ;  ication  be  established  on  a 
different  subject,  please  contact  Joan  Buntzen,  x34879. 

Acoustics 

Antennas 

Applied  Mathematics 
Arctic 

Artificial  Intelligence 

Command  and  Control 

Communication  Systems  and  Equipment 

Communication  Theory 

Data  Communication 

Display  Systems 

Feedback  and  Control  Theory 

Fiber  Optics 

Image  Processing 

Laser  Applications 

Matrix  Materials 

Microelectronics 

Numerical  Analysis 

Oceanography 

Optics 

Program  Management 
Radar 

Radio  Noise 

Reliability 

Robotics 

Semiconductors  and  Transistors 
Signal  Processing 
Software  Engineeiing 

Software  Quality,  Reliability,  and  Documentation 

Individually  tailored  current  awareness  searches  may  be  established  with  any  of  the  online  services  listed 
below.  Contact  Joan  Buntzen,  x34879,  for  further  information. 

DTIC 

NASA 

BRS 

DIALOG 

ORBIT 


REQUEST  FOR  LITERATURE  SEARCH 
NOSC  TECHNICAL  LIBRARY 


SEARCH  TOPIC 


Code _ 

Phone _ (  )  Call  me  for  pickup 

(  )  Mail  search  to  me 

Date _ Date  Required _ 


Please  provide  a  narrative  statement  of  your  topic.  Define  any  terms  that  may  have  special  meaning 
in  your  request.  Indicate  areas  to  be  excluded.  Include  significant  phrases,  synonymous  terms,  relevant 
authors,  companies,  agencies,  etc.,  or  pertinent  citations.  BE  AS  SPECIFIC  AS  POSSIBLE. 


SEARCH  SPECIFICATIONS 

Specificity:  Exhaustive _  Specific _  Few  key  articles 

Time  coverage: _ (no.  of  years) 

Language:  All _ Eng.  only _ 

Highest  classification: _ 

DA  TA BASES  TO  BE  SEARCHED 

_ NOSC  Library  Holdings 

DTIC: 

_ Technical  Reports 

_ Work  Units  (1498’s) 

_ Industrial  IR&D 

_ Program  Planning 


Periodical/open  literature: 

_ DIALOG 

_ BRS 

_ ORBIT 

_ NASA 

_ Other  (please  specify) 


Figure  16.5.  Request  for  NOSC  library  literature  search. 


16.5  EFFECTIVE  PRESENTATIONS 

Presentations  come  with  the  territory;  presentation  demands  are  made  on  project  managers  at 
the  Naval  Ocean  Systems  Center.  Technical  presentations  or  briefings  are  often  vital  to  obtaining  support, 
selling  your  ideas,  or  defining  the  scope  and  requirements  of  your  project.  The  professional  image 
you  portray,  how  you  organize  and  present  material,  the  visual  aids  you  choose  to  help  you,  how  you 
deliver  the  message,  can  all  mean  success  or  failure  in  your  presentations. 

Your  oral  presentation  may  be  given  in-house  to  your  peers  or  management.  When  you  gain  a 
reputation  for  giving  effective  presentations,  you’ll  benefit  from  a  “halo”  effect  that  carries  over  to 
other  job  activities.  If  your  presentation  is  given  to  others,  the  impression  you  make  on  your  audience 
will  also  reflect  the  image  of  the  Naval  Ocean  Systems  Center.  If  you’re  well-organized,  sharp,  concise, 
and  self-confident,  NOSC  will  be  regarded  as  an  efficient  and  professional  organization. 

The  few  minutes  of  your  presentation  may  reflect  years  of  background,  months  of  study  and  data 
accumulation,  and  days  or  maybe  even  weeks  of  preparation.  In  many  instances,  those  few  minutes 
can  affect  management  decisions  and  the  expenditure  of  large  sums  of  money. 

As  a  result,  presentation  skills  are  important  to  you  as  a  project  manager  and  each  briefing  requires 
careful  and  intelligent  attention. 

The  NOSC  Presentation  Workshop  is  given  periodically  for  NOSC  personnel.  It  has  strong  support 
from  upper  management.  It  was  designed  to  not  only  give  you  individualized  instruction  in  speaking 
and  presentation  tecnniques,  but  to  familiarize  you  thoroughly  with  the  audiovisual  and  graphics  support 
you  have  available  here  at  the  Center. 

Two  publications  are  recommended  for  those  preparing  presentations: 

Effective  Business  and  Technical  Presentations ,  by  George  L.  Morrisey 
How  to  Prepare ,  Stage,  and  Deliver  Winning  Presentations ,  by  Thomas  Leech 

The  tables  that  follow  present  a  series  of  ready  reference  materials  that  are  concise  but  thorough 
enough  to  be  of  significant  help  in  preparing  effective  presentations.  Use  them. 

Table  16.5.  Criteria  for  selection  of  resource  material 
Table  16.6.  How  to  plan  and  organize  your  presentation 
Table  16.7.  Audience  analysis 
Table  16.8.  The  presentation  outline 
Table  16.9.  How  to  give  your  presentation 
Table  16.10.  Preliminary  arrangements  checklist 
able  16.11.  Visual  aids 
Table  16.12.  Odds  and  ends 


Table  16.5.  Criteria  for  selection  of  resource  material. 

What  is  the  OBJECT  or  PURPOSE  of  the  presentation? 

What  kind  of  AUDIENCE  ACTION  or  RESPONSE  is  required? 

What  MUST  be  said  to  reach  objectives? 

What  is  the  BEST  way  to  say  it?  What  method  to  use? 

What  amount  of  DETAIL  is  necessary? 

What  material  should  be  WITHHELD,  but  available  for  question/answer  period? 
Submit  all  resource  materials  to  the  “WHY”  test. 

Table  16.6.  How  to  plan  and  organize  your  presentation. 

DETERMINE  PURPOSE 

State  in  one  concise  sentence 

ANALYZE  YOUR  AUDIENCE 

Size,  attitude,  background,  relationship 

PREPARE  PLAN 

Main  ideas  or  concepts,  supporting  material 

SELECT  RESOURCE  MATERIALS 
Submit  all  to  the  “WHY”  test 

ORGANIZE  WELL 
Opening,  body,  close 

PRACTICE 


Rehearse,  rehearse,  rehearse 
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Table  16.7.  Audience  analysis. 

How  much  do  they  know  about  the  subject? 

Are  they  at  the  decision  making  level? 

What  ianguage  will  they  best  understand: 

Technical,  business,  financial,  everyday  English,  or  what? 

Are  there  leaders  in  the  group  who  could  sway  the  rest? 

Should  I  address  myself  to  the  whole  group,  or  only  certain  ones? 

What  are  their  reasons  for  attending  my  presentation? 

What  information  or  technique  is  likely  to  gain  their  attention? 

What  information  or  technique  is  likely  to  get  negative  reactions? 

Audience  attitude?  Friendly,  unfriendly,  etc. 

Will  they  be  in  a  hurry  to  conclude? 

Is  there  likely  to  be  opposition,  or  even  debate? 

Does  anyone’s  face  need  to  be  saved? 

Is  there  likely  to  be  a  bias,  either  pro  or  con? 
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Table  16.8.  The  presentation  outline  (1  of  2). 


Title  or  Subject: . 


Purpose  (state  in  one  clear,  concise  sentence) 


Opening: 


Main  ideas  or  Concepts 


Information  necessary  to  support  the  main  idea: 


Idea  1 


Idea  2 


fl 
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Table  16.8.  The  presentation  outline  (cont’d.) 


Idea  3 


Idea  4 


Closing:  Summary  —  The  points  made: 

1.  _ 

2.  _ 

3.  _ 

4.  _ 


The  recommendation: 
OR  the  conclusions:  _ 


Therefore,  the  action  I  want  from  you 


9 
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Table  16.9.  How  to  give  your  presentation. 


THE  TOTAL  IMPRESSION 

Professional  —  Confidence,  Alertness,  Poise 

THE  LOOK 

Appearance  —  Affects  attitudes,  answers  questions 
Affects  opinion,  reinforces  feelings 
Dress  like  occasion  demands 
Be  comfortable 
Nothing  distracting 

LECTERN  PRESENCE 

Bearing  —  Posture,  movements 

Hand  gestures  —  Relax,  never  make  gestures  consciously,  key  is  natural, 
don’t  play  with  items  you  hold 
Body  gestures  —  Move  with  purpose,  avoid  pacing 
Eye  contact  —  Use  it 
Lectern  —  Establishes  formal  relationship 

VOICE 

Volume,  rate,  modulation 
Pause  —  Effective  means  of  emphasis 
Watch  filler  words/pet  phrases 
Be  aware  —  Enunciation/voice  drop 

DEVELOP  STYLE 

Personality  —  warmth/sincerity/enthusiasm 

Never  imitate 

Discover  personal  strength 

MEMORY  AIDS 

Avoid  hazards  of  memorizing 
Visuals  keep  “on  track” 

Use  notes  if  more  comfortable 
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Table  16.10.  Preliminary  arrangements  checklist 


GENERAL  INFORMATION 

Presenter  _ 

Subject _ 

Audience _ 

Date _ 

Security  Classification 

ROOM 

□  Room  Reserved 

□  Arrangement 

□  Chairs 

□  Tables 

□  Lighting 

□  Ventilation 

□  Distractions 

□  Other _ 


Number 
Time _ 


PRESENTATION  MATERIAL 

□  Visual  Aids 

□  Film/Tapes 

□  Hardware/Models/Demonstraiions 

□  Handouts  (quantity) 

□  Other _ 


*1151. 


EQUIPMENT  (Test  Everything) 

□  Placement 

□  Accessories  (bulb,  extension  cord,  etc.) 

□  Sound  System 

□  Lectern 

□  Pointer 

□  Marker/Chalk 

□  Other  _ 

SUPPLIES 

□  Tablets 

□  Pencils 

□  Name  Cards 

□  Other  _ 

PROVISIONS 


□  Refreshments 

□  Breaks 

□  Other  _ 
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Table  16.11.  Visual  aids. 


WHY  VISUALS? 

People  are  visual-minded 
Retention  is  increased 
Visualization  encourages  organization 
Puts  you  in  action 

You  and  the  Audience  are  side  by  side 
Misunderstandings  are  less  likely  to  occur 

VISUALS  SHOULD 

Illustrate 
Focus  attention 
Clarify 

GENERAL  RULES 

Keep  them  simple 
Make  them  readable 
Use  key  words 
Use  consistent  style 
No  more  than  7  items 

TYPES  OF  VISUALS 

Boards 

Pictorials 

Charts 

Objects/Models 
Projections 
Handout  Materials 
Auditory  Aids 
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Table  16.12.  Odds  and  ends. 


SITUATION 

Where  given  —  never  ignore  details,  arrive  early,  check  facilities,  check  equipment  for  visuals 

Time  limit  —  no  excuse  for  running  over 

Place  on  Program  —  make  adjustments  accordingly 

Handout  Material  —  pass  out  after  talk 


ANALYZING  AUDIENCE  FEEDBACK 
Remain  objective 

Don’t  continue  without  audience  contact 


AUDIENCE  RETENTION 

Strong  introduction  and  conclusion 
Need  for  closing  phrases 


QUESTION  AND  ANSWER  PLRIOL 

Advantages  —  message  reinforced,  valuable  feedback 
Planning  —  allow  time,  prepare  audience,  prepare  yourself 
Handling  —  getting  it  started,  heard  by  ail,  give  everyone  a  chance 

Analyzing  —  spot  loaded  questions,  divide  complex  questions,  accept  nonquestions,  dismiss 
irrelevant  questions,  handling  long-wiu^j  questions 
Answer  directly 
Stick  to  your  specialty 
Keep  it  moving 

Concluding  —  stop  while  •-  ip-Vc  the  end,  close  with  summary  statement 
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SECTION  17 

COMPUTERIZED  ASSISTANCE 


17.1  INTRODUCTION 

17.1.1  Summary 

This  presentation  serves  to  introduce  you  to  a  variety  of  computer  resources  and  services  available 
to  NOSC  project  managers.  A  distinction  is  made  between  computer-based  tools,  which  can  help  you 
perform  project  management  functions,  and  the  actual  performance  of  the  functions  of  planning, 
budgeting,  or  project  monitoring.  A  survey  of  hardware,  software,  and  support  services  is  provided 
and  includes  a  number  of  tools  to  help  you  perform  most  of  your  work  on  a  personal  computer.  The 
presentation  concludes  with  a  preview  of  resources  and  tools  that  are  in  development  or  are  planned. 


17.2  WHAT  IS  A  COMPUTER  TOOL? 

A  dictionary  defines  a  tool  as  “"anything  used  in  the  performance  of  an  operation;  an  instrument” 
and  “anything  regarded  as  necessary  to  the  carrying  out  of  one’s  occupation . . . .”  On  that  basis,  a 
computer  tool  could  be  defined  as  any  computer  resource,  be  it  hardware,  software,  or  procedure, 
that  can  assist  in  the  performance  of  a  task.  Remember  that  use  of  these  tools  is  not  a  substitute  for 
planning,  budgeting,  or  project  monitoring  but  can  assist  in  these  types  of  activity. 

17.2.1  Some  Comparisons  of  Tools 

The  following  comparisons  of  computer  tools  and  their  noncomputer  equivalents  illustrate  a  few 
possibilities: 

Conversation:  Telephone 

Writing:  Typewriter 

Distribution:  Guard  mail 

Document  storage:  File  Cabinet 

Accounting:  Ledger  book 

Record  Keeping:  3  by  5  cards 

17.2.2  How  Can  Electronic  Mail  be  Used? 

One  of  the  most  popular  computer  tools  at  the  Center  is  electronic  mail.  It  can  be  used  to  exchange 
messages  and  reduce  “telephone  tag.”  It  can  also  be  used  to  broadcast  announcements  to  project 
members,  line  management,  and  sponsors.  It  can  provide  an  effective  means  to  distribute  drafts  of 
documents  for  review,  to  exchange  comments  or  changes,  and  to  submit  for  final  approval. 


17.3  WHAT  COMPUTER  RESOURCES  ARE  AVAILABLE? 

Computer  resources  at  NOSC  may  be  divided  into  four  major  categories:  project  resources, 
departmental  resources,  personal  computers,  and  Center  services. 


—  Electronic  mail 

—  Word  processing 

—  Electronic  mail 

—  File  system  on  disk 
Tape  archive 

—  Spreadsheet 

—  Database  management  system 


17.3.1  Project  Resources 


There  are  more  than  80  VAX  minicomputers  throughout  the  technical  and  support  codes.  The 
majority  are  run  under  the  VMS  operating  system.  Many  are  operated  as  classified  processors,  and 
most  are  restricted  to  specific  projects. 

17.3.2  Departmental  Resources 

A  number  of  departmental  resources  are  available  at  NOSC.  These  are  independent  and 
complementary  to  the  Center  resources.  The  largest  is  the  Code  80  service  center  which  features  a  variety 
of  VMS  tools,  including  word  processing,  a  VMS  mail  gateway  to  Center  email,  scientific  packages, 
spreadsheets,  graphics  utilities,  and  a  project  management  package. 

17.3.3  Personal  Computers  at  NOSC 

Personal  computers  have  become  the  resource  of  preference  for  many  NOSC  personnel,  and  PC 
use  continues  to  grow  dramatically.  By  the  end  of  FY86,  there  were  over  3,000  PCs  on  Center.  That 
number  grew  to  nearly  4,000  by  the  end  of  FY87.  Of  these,  about  three  quarters  are  IBM  PC/XT/AT 
or  IBM  compatibles  (primarily  Zenith  Z248s).  Another  10  percent  are  Macintosh.  An  important 
consideration  for  all  PC  users  is  the  compatibility  of  the  hardware  with  NOSC’s  local  area  network, 
referred  to  as  the  Generalized  Communications  Backbone  (GCB). 

17.3.3.1  What  Tools  are  Available  for  PCs?  There  are  hundreds  if  not  thousands  of  PC  software 
packages  developed  annually.  A  number  of  these  have  been  evaluated  and  endorsed  by  the  Centerwide 
Office  Automation  Network  (COAN)  Project.  Technical  and  user  support  of  these  programs  is  available 
through  the  Topside  and  Bayside  Computer  Resource  Centers  (CRCs).  Examples  include 

Spreadsheets  —  Lotus,  Supercalc 

Database  managers  —  dBase  III,  Rbase  5000 

Word  processors  —  Easy  Editor,  Wordstar,  WordPerfect,  WordMARC 

Project  managers  —  Time  Line 

Graphics  —  Dr.  Halo,  Chartmaster,  Sound  Presentation 

Calendars/Organizers  —  Sidekick 

Many  PCs  are  used  in  conjunction  with  minicomputers,  either  as  terminals  c .  tor  uploading/down¬ 
loading  of  data  or  text  files.  Tools  are  available  for  these  functions  including  several  programs  that 
are  free  from  either  CRC.  These  free  products  include  VT100  terminal  emulation  (terminal.exe), 
intercomputer  transfers  (terminal.exe  on  PC  and  mcp  on  Unix,  VMS),  and  downloading  of  institutional 
data  (PCLink). 

17.3.4  Center  Services 

A  number  of  computer  resources  and  services  are  provided  Centerwide  by  the  Computer  Sciences 
and  Simulation  Division,  Code  91.  These  include  the  GCB,  the  Defense  Data  Network  (DDN),  the 
General  Purpose  Computer  Center’s  (GPCC’s)  VAX  network,  two  Computer  Resource  Centers,  a 
Computer  Training  Center,  and  an  applications  development  service. 


17.3.4.1  Generalized  Communications  Backbone  (GCB).  The  GCB  is  a  broadband  communications 
facility  based  on  cable  television  technology.  It  runs  between  and  inside  buildings  throughout  NOSC. 
Its  principal  use  today  is  for  host-terminal  communications.  Future  emphasis  will  be  for  PC-to-PC 
and  intelligent  workstation  networks.  The  GCB  is  capable  of  supporting  video,  audio,  and  RF 
applications. 

17.3.4.2  Defense  Data  Network  (DDN).  The  DDN  provides  communication  between  DoD  and  non- 
DoD  research  centers  around  the  world.  The  MILNET  is  the  unclassified  network  component  of  the 
DDN.  A  classified  network  is  planned  and  partially  implemented.  The  principal  local  uses  are  for 
electronic  mail  to  other  activities  (e.g.,  SPAWAR,  other  laboratories);  remote  login  to  host  computers 
at  other  facilities;  and  file  transfers  between  computers.  When  a  NOSC  employee  is  on  travel,  remote 
access  to  NOSC’s  computers  is  generally  possible  via  the  DDN  through  a  local  phone  call  to  a  Terminal 
Access  Controller  (TAC). 

17.3.4.3  Code  91  VAX  Network.  As  part  of  the  General  Purpose  Computer  Center  (GPCC),  Code 
912  operates  a  number  of  VAXes  as  timeshared  resources.  At  present  there  is  an  8650  (Manta);  three 
8600s  (Cod,  Marlin,  Wahoo);  a  785  (Trout);  and  a  750  (Humu,  in  Hawaii).  These  are  all  connected 
to  the  GCB  and  interconnected  via  Ethernet.  The  operating  system  is  4.3  BSD  (Berkeley)  Unix  except 
for  Wahoo,  which  runs  under  VMS  Version  4.  A  recent  addition  to  the  GPCC’s  equipment  suite  is 
a  Convex  Cl-XP  minisupercomputer  that  also  runs  under  Berkeley  Unix. 

A  number  of  tools  are  available  on  the  GPCC  VAXes.  These  include  electronic  mail  (provided 
free  to  all  NOSC  employees);  the  Project  Management  Support  System  (PMSS);  and  a  variety  of  general 
purpose  resources  for  editing,  word  processing,  database  management,  and  scientific  computation  and 
analysis. 

17.3.4.4  Project  Management  Support  System  (PMSS).  PMSS  consists  of  a  collection  of  locally 
developed  software,  hardware,  documentation,  training,  and  consultation.  PMSS  was  conceived  and 
designed  to  provide  rapid  access  to  project  information  electronically.  PMSS  currently  resides  on  Marlin, 
Manta,  and  Humu.  It  features  access  to  an  on-line  database  containing  NOSC  financial  data.  Financial 
data  can  be  downloaded  to  Lotus  or  dBase  files  on  PCs.  Data  available  include  job  order  information; 
stub  status;  plant  account  information;  material/service/travel  (MST)  reports;  and  employee  activity 
(charges,  plant  property). 


17.4  WHAT  ASSISTANCE  IS  AVAILABLE? 

The  GPCC  staff  offers  assistance  in  several  ways.  Consultation  is  provided  from  both  CRCs.  The 
consultants  serve  as  a  single  point  of  contact  for  the  GPCC.  They  handle  new-user  signups  and  DDN/TAC 
signups.  They  also  provide  technical  consultation  or  referral  on  a  wide  variety  of  computer  topics. 
PC  support,  including  PC  maintenance,  is  available  through  the  CRCs.  Customers  may  contact  either 
CRC  location  via  phone,  email,  or  by  visiting  in  person. 

Computer  classes  are  regularly  offered  in  the  GPCC’s  computer  training  classroom.  PC,  Unix, 
and  VMS  classes  are  conducted.  Schedules  are  published  in  the  monthly  Computing  Highlights. 

An  applications  development  service  is  offered  whereby  small  tasks  can  be  handled  on  a  chargeback 
basis.  The  initial  consultation  and  scoping  of  the  effort  is  at  no  charge.  Applications  development  projects 
are  limited  to  80  hours  of  design  and  programming  effort. 


Computer  documentation  is  available  from  the  GPCC.  Commercial  textbooks  on  Unix  and  PC 
topics  may  be  reviewed  and  ordered  through  the  CRC  or  the  technical  libraries.  Most  of  the  titles  are 
stocked  and  will  be  delivered  within  2  working  days.  Locally  produced  documents  are  also  prepared 
and  distributed,  including  the  PC  Owners  Manual,  an  email  user’s  guide,  a  DDN  user’s  guide,  and 
the  GPCC  Survival  Guide. 

PC  support  in  addition  to  the  services  descibed  is  available  through  the  CRCs.  This  support  includes 
hands-on  exposure  to  PC  hardware  and  software,  guidance  and  assistance  for  PC  procurements, 
assistance  for  PC  installation  and  check-out,  and  distribution  of  public  domain  and  local  software. 
The  two  CRCs  serve  as  satellite  depots  for  computer-related  shopstores  stock  items,  such  as  printer 
supplies,  diskettes,  cables,  and  software.  Recently,  complete  Z248  PC  systems  (AT  equivalent)  were 
added  to  the  shopstores’  catalog,  so  it  is  now  possible  to  procure  a  PC  from  locally  maintained  inventory. 
Finally,  PC  maintenance  by  on-site  contractor  personnel  may  be  arranged  by  contacting  either  CRC. 


17.5  A  NOTE  ON  COMPUTER  SECURITY 

As  a  reminder  that  computers  at  NOSC  are  often  used  for  classified  or  sensitive  applications,  certain 
security  measures  may  be  required  when  you  are  acquiring,  developing,  using,  or  reconfiguring  these 
resources.  Guidance  is  available  from  your  division  ADP  System  Security  Officer  (DADPSSO),  the 
ADP  Security  Office  (Code  153),  OPNAVINST  5239.1A,  and  NOSCINST  5500.1A. 


17.6  PLANS  FOR  FUTURE  RESOURCES  AND  TOOLS 

There  are  several  efforts  in  progress  which  we  hope  will  result  in  further  improvements  in  how 
effectively  we  use  PCs  and  minicomputers  at  NOSC.  These  efforts  include 

•  PC-based  electronic  mail  (micromail) 

•  Integrated  email  for  all  NOSC  employees 

•  Electronic  paperwork  tools  (stubs,  travel  orders,  etc.) 

•  Electronic  signature  system 

•  Expanded  CRC  facilities  and  services 

•  More  PC,  Unix,  and  VMS  training  and  support 
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SECTION  18 

COMPUTER-AIDED  LOGISTICS 


18.1  INTRODUCTION 


18.1.1  References 

MIL-STD-1388-1A,  Logistic  Support  Analysis  (LSA) 

MIL-STD-1388-2A,  DoD  Requirements  for  a  Logistic  Support  Analysis  Record  (LSAR) 
DoD  Instruction  5000.2,  Major  Systems  Acquisition  Procedures 
SECNAVINST  4130.2,  Department  of  the  Navy  Configuration  Policy 
DoD  Directive  5000.39,  Acquisition  and  Management  of  Integrated  Logistic  Support  for  Systems 
and  Equipment 


18.2  REQUIREMENTS 

To  understand  the  objectives  of  logistics  support  properly,  it  is  necessary  to  examine  briefly  the 
prime  requirements  for  systems  acquisitions.  These  may  be  expressed  simply  as 

a.  IT  MUST  DO  WHAT  IT  IS  SUPPOSED  TO  DO  WHEN  IT  IS  SUPPOSED  TO  DO  IT.  This 
factor  is  obviously  related  to  system  performance  and  reliability. 

b.  IT  MUST  BE  ADEQUATELY  DOCUMENTED.  Adequately  documented  is  a  term  that  needs 
some  degree  of  logical  interpretation.  Adequately  is  the  key  word  here.  A  full  level  3  documen¬ 
tation  package  may  not  be  required  on  a  “one  of  a  kind’’  system  not  intended  for  production. 
However,  a  level  of  documentation  suitable  for  repair,  adjustment,  operation,  special 
transportation  requirements,  safety,  purchasing  repair  parts,  etc.,  would  certainly  be  prudent 
and  well  advised. 

c.  IT  MUST  BE  AFFORDABLE.  Logistically  this  term  is  normally  defined  in  terms  of  money 
and  resources  over  the  life  of  the  system. 

d.  IT  MUST  BE  SUPPORTABLE.  The  term  supportable  is  normally  interpreted  as  logistics 
functions.  Unfortunately,  it  is  not  quite  so  obvious  that  logistic  requirements  and  data  cover 
the  three  other  areas  as  well. 

The  logistics  requirements  include  the  need  for  spare  parts.  The  parts  are  identified  in  the 
configuration  management  documentation.  The  number  of  parts  required  is  dependent  upon 
reliability  and  other  logistics  factors.  The  cost  of  the  total  number  of  spare  parts  and  the  other 
logistical  factors  have  major  impacts  on  a  system’s  affordability. 


18.3  IMPORTANT  FACTS 


a.  Out  of  every  $1  that  will  be  spent  on  a  system  acquisition  over  its  LIFE  CYCLE,  75  cents  will 
be  “locked  in”  during  the  demonstration  and  validation  phase. 

b.  Out  of  every  $1  that  will  be  spent  on  a  system  acquisition  over  its  LIFE  CYCLE,  a  total  of 
85  cents  (10  cents  additional)  will  be  “locked  in”  during  the  full-scale  development  phase. 

c.  Approximately  75  percent  of  all  Navy  programs  undergoing  a  logistic  review  group  (LRG)  audit 
for  logistics  certification  to  proceed  to  DSARC  fail. 

d.  Approximately  35  percent  fail  on  their  SECOND  attempt. 

18.4  WHAT  IS  THE  TECHNICAL  LIFE  CYCLE? 

LIFE  CYCLE  OF  TECHNICAL  ACTIVITIES 

System  Phase  Time  in  Years 

Concept  exploration  0-2 

Demonstration/validation  2-3 

Full-scale  development  3-6 

Technical  directions  agent  (TDA)  function  5-11 

5-11 

Production  and  deployment  3-5 

Operation  and  support  15-40 

In-service  engineering  agent  (ISEA)  function  18-45 

18-45 

Total  system  life  cycle  in  years  23-56 


18.5  CHANGING  SCOPE  OF  LOGISTIC  REQUIREMENTS  AND  PERCEPTIONS 

As  pointed  out  in  the  previous  paragraph,  the  typical  system  life  cycle  will  range  between  a  quarter 
to  a  half  century!  Reference  to  Figure  18.1,  change  in  logistic  requirements  and  perceptions,  graphically 
shows  what  an  impact  the  new  requirements  impose.  Prior  to  1983,  the  application  of  the  logistic  support 
analysis  (LSA)  with  its  companion  logistic  support  analysis  record  (LSAR)  was  to  a  large  extent  optional 
in  the  early  phases  and  totally  disappeared  shortly  after  deployment.  The  current  directives  introduce 
logistical  considerations  during  the  preconcept  phase  and  maintain  them  into  the  disposal  phase. 

Figure  18.1  shows  a  change  in  the  lines  for  new  scope  during  the  production/deployment  phase. 
This  change  to  an  open  line  represents  a  reduction  of  effort  in  the  LSA  and  LSAR  activity.  A  key 
point  to  remember  is  that  the  logistical  requirement  does  not  go  away  over  the  entire  life  cycle  of  the 
system.  At  the  end  of  the  TDA  function  it  is  transitioned  to  the  ISEA  and  Program  Office  with  the 
LSAR  database. 


NC 


Figure  18.1.  Change  in  logistic  requirements  and  perceptions. 


It  has  frequently  been  said  that  logistical  planning  is  the  function  of  the  prime  hardware  contractor. 
Nothing  could  be  further  from  the  truth.  The  logistical  planning  of  an  acquisition  is  a  government 
responsibility.  True  it  is  accomplished  with  inputs  from  many  sources  including  the  prime  hardware 
contractor,  support  from  service  contractors,  other  government  agencies,  etc.,  but  the  prime  responsibility 
is  that  of  the  acquisition  program.  This  statement  normally  translates  to  a  TDA  function. 


18.6  BASIC  GUIDANCE 

There  are  approximately  340  +  documents  within  the  Navy  that  are  directly  involved  with  the  subject 
of  logistics.  Fortunately,  it  is  highly  unlikely  that  the  majority  of  them  would  be  applied  to  a  single 
acquisition. 

The  easiest  approach  to  defining  logistical  requirements  of  an  acquisition  is  covered  in  two  basic 
documents. 

a.  MIL-STD-1388-1A,  Logistic  Support  Analysis  (LSA) 

b.  MIL-STD-1388-2A,  DoD  Requirements  for  a  Logistic  Support  Analysis  Record  (LSAR) 

These  two  documents  implement  the  guidelines  and  requirements  established  by  DoD  Instruction 
5000.2,  Major  Systems  Acquisition  Procedures,  and  DoD  Directive  5000.39,  Acquisition  and 
Management  of  Integrated  Logistic  Support  for  Systems  and  Equipment. 


18.7  A  MUCH-NEEDED  CLARIFICATION 

On  1 1  May  1987,  the  Assistant  Secretary  of  the  Navy,  the  Honorable  Everett  Pyatt,  implemented 
SECNAVINST  4130.2,  Department  of  the  Navy  Configuration  Policy.  This  Navy  document  specifically 
identifies  what  integrated  logistic  support  is  and  what  comprises  it  for  the  Navy. 

18.7.1  What  is  Integrated  Logistic  Support? 

Integrated  logistic  support  is  a  disciplined,  unified,  and  iterative  approach  to  the  management 
and  technical  activities  necessary  to 

•  Integrate  support  considerations  into  system  and  equipment  design; 

•  Develop  support  requirements  that  are  related  consistently  to  readiness  objectives,  to  design, 
and  to  each  other; 

•  Acquire  the  required  support; 

•  Provide  the  required  support  during  the  Operating  and  Support  phase  at  minimum  cost. 

18.7.2  What  Comprises  Integrated  Logistic  Support? 

Integrated  logistic  support  is  comprised  of  the  following  elements: 

•  Maintenance  planning 

•  Manpower  and  personnel 

•  Supply  support  (including  initial  provisioning) 


•  Support  equipment 

•  Training  and  training  support 

•  Technical  data 

•  Computer  resources  support 

•  Packaging,  handling,  storage,  and  transportation 

•  Facilities 

•  Design  interface 


18.8  A  WORD  ABOUT  TECHNICAL  DATA 

Technical  data  is  defined  by  SECNAVINST  4130.2  as 

Recorded  information,  regardless  of  form,  used  to  define,  produce,  test,  evaluate,  modify,  deliver, 
support,  maintain  or  operate  a  configuration  item.  Technical  data  may  be  recorded  as 

•  graphic  or  pictorial  delineations  in  media  such  as  drawings  or  photographs 

•  text  bin  specifications  or  related  performance  or  design  documents 

•  machine  forms  such  as  punched  cards,  magnetic  tape,  disks,  or  computer  memory 
printouts 

Examples  of  technical  data  include  engineering  drawings  and  associated  lists,  specifications, 
standards,  process  sheets,  commercial  item  descriptions,  manuals,  test  and  evaluation  master 
plans  and  reports,  technical  reports,  catalog  and  item  identifiers,  logic  diagrams,  flow  charts, 
and  minutes  of  technical  reviews  and  configuration  audits.  Research  and  engineering  data  are 
included,  but  financial  and  administrative  data  are  not. 

18.9  A  WORD  OF  CAUTION 

Although  financial  data  are  not  considered  logistic  technical  data,  it  should  be  recognized  that 
there  is  a  significant  interplay  between  the  financial  and  logistic  considerations. 

•  Program  management  should  draw  upon  logistic  estimates  for  Program  Objectives  Memorandum 
(POM)  funding  levels. 

a.  The  POM  cycle  establishes  acquisition  program  funding  requirements  for  periods  up 
to  5  years  in  advance. 

b.  A  large  percentage  of  funding  shortfalls  can  be  traced  to  mandatory  logistic 
requirements  that  were  totally  ignored  for  funding. 

c.  The  mandatory  nature  of  the  requirement  can  force  the  reprogramming  of  available 
funds  to  meet  the  need.  On  occasion,  this  has  led  to  the  purchase  of  fewer  numbers 
of  the  end  item  or  system. 

•  Life  cycle  cost  and  supportability  analyses  interact  very  heavily  with  the  program  funding  past, 
present,  and  future. 


•  All  program  personnel  should  be  aware  that  funding,  although  uot  classified  as  technical  data, 
is  an  intimate  part  of  supportability  planning  for  future  dollars  to  support  the  acquisition 
program. 


1&10  WHAT  ARE  THE  PROGRAM  MANGER'S  ILS  RESPONSIBILITIES? 

The  following  paragraphs  an  extracted  from  the  DoD  Directive  5000.39,  “Acquisition  and 
Management  of  Integrated  Logistic  Support  for  Systems  and  Equipment.”  While  application  of  the 
following  paragraphs  to  major  systems  is  mandatory,  the  directive’s  use  as  a  guideline  for  less-than- 
major  systems  is  highly  recommended. 

THE  PROGRAM  MANAGER'S  ILS  RESPONSIBILITIES 

1.  The  program  manager  shall  address  support  in  determining  contract  structure,  type,  and 
competition.  As  a  normal  course  of  action,  source  selection  criteria  and  contract  performance  clauses 
shall  be  used  to  provide  contractors  incentive  to  deliver  systems  that  meet  the  R&M  and  support 
objectives.  Source  selection  evaluation  criteria  for  appropriate  competitive  programs  shall  include  a 
separate  evaluation  factor  (separate  from  schedule,  cost,  and  performance)  for  readiness  and  support, 
weighted  to  ensure  a  positive  effect  on  contractor  selection  and  contract  award.  To  the  maximum  extent 
practical,  ILS  contract  requirements  shall  be  identified  under  definite  contract  line  items.  If  extended 
contractor  support  is  planned,  development  and  production  contract  requirements  shall  include  delivery 
of  data  needed  for  an  effective  strategy  for  the  follow-on  procurement  of  support. 

2.  The  program  manager  shall  address  manpower,  personnel,  and  training  requirements  throughout 
the  acquisition  phases  by 

a.  Including  in  solicitations,  requests  for  design  and  support  approaches  to  minimize  manpower, 
personnel,  and  training  requirements. 

b.  Providing  contractors  with  manpower,  personnel,  and  training  data  (including  data  from  fielded 
systems)  in  sufficient  detail  for  design  trade-offs  and  requirements  determination. 

c.  Ensuring  that  manpower,  personnel,  and  training  cost  factors  furnished  for  design  and  support 
trade-off  analyses  take  into  account  costs  to  retain  or  replace  experienced  personnel  as  well 
as  billet  costs. 

d.  Structuring  contractor  incentives,  when  appropriate,  to  reward  successful  development  of 
training  approaches  and  maintainable  designs  based  on  operational  demonstrations  late  in 
development  or  early  in  production. 

3.  The  program  manager  shall  develop  an  ILS  plan  by  Milestone  I  and  keep  it  current  throughout 
acquisition.  The  ILS  plan  shall  integrate  logistics  aspects  of  the  program.  Positive  controls  shall  be 
established  to  integrate  schedules  and  to  identify  interdependences  among  the  ILS  elements,  design 
activities,  and  deployment  plans.  The  ILS  plan  shall  document  readiness  and  support  objectives  and 
demonstrate  achievements,  operating  concepts,  and  deployment  requirements  (including  transportability), 
support  concepts  and  plans,  ILS  element  requirements,  schedule,  funding  requirements,  and 
responsibilities  for  ILS  activity  planned  for  each  program  phase.  For  multi-DoD  Component  programs, 
the  ILS  plan  shall  address  the  support  requirements  of  all  participating  DoD  Components. 

4.  The  program  manager  shall  furnish  contractors  with  appropriate  government  data,  such  as 
a  baseline  operating  scenario  and  maintenance  concepts,  system  readiness  objectives,  and  support  costs 
on  current  systems  in  use  as  a  basis  for  contractor  ILS  planning  and  analysis. 


5.  The  program  manager  shall  maintain  current  ILS  management  information  (including  details 
of  schedule,  resource  requirements  and  funding,  LSA  documentation,  and  the  status  of  progress  toward 
support-related  thresholds)  to  support  ILS  planning  and  management  decisions.  Standard  data  elements 
shall  be  developed  and  used  to  the  extent  possible.  The  work  breakdown  structure  established  for  the 
program  in  accordance  with  DoD  Directive  5010.20  and  MIL-STD  881A  (Work  Breakdown  Structures 
for  Defense  Materiel  Items)  shall  be  used  as  the  framework  for  cost  reporting. 

6.  The  program  manager  shall  maintain  visibility  of  all  essential  resource  requirements  to  assess 
the  extent  to  which  the  budgeted  and  programmed  resources  are  or  will  be  available  to  meet  these 
requirements  and  the  effect  of  any  shortfalls  on  support  schedules  and  attainment  of  readiness  objectives. 
The  program  shall  have  an  explicit  coordinating  role  in  programming,  budgeting,  and  budget  execution 
affecting  system  readiness.  Traceability  of  changes  in  support  budgets  and  support-related  objectives 
and  thresholds  (including  changes  in  definition)  shall  be  maintained  in  DoD  Component  management 
information  systems. 

7.  The  program  manager  shall,  by  the  production  decision  point,  develop  plans  for  follow-on 
readiness  assessment,  beginning  initial  deployment  and  continuing  until  the  system  design  and  support 
configuration  are  mature.  These  plans  shall  include  milestones,  responsibilities,  and  acquisition  strategies 
for  making  system  design  and  support  resource  improvements  needed  to  meet  system  readiness  objectives. 

8.  By  the  production  decision  point,  plans  shall  include  resource  requirements,  milestones, 
responsibilities  and  strategies  for  making  software  design  and  support  improvements  needed  to  meet 
system  readiness  and  effectiveness  goals  following  deployment. 

9.  Plans  s^"M  be  developed  beginning  at  the  production  decision  point  and  updated  periodically 
in  the  production  phase  to  determine  the  cost-effective  means  of  providing  postproduction  support. 
A  DoD  Components  postproduction  support  review  shall  be  held  sufficiently  in  advance  of  production 
phaseout  to  ensure  that  plans,  resources,  and  responsibilities  are  established  for  effective  postproduction 
support  to  meet  readiness  objectives. 


18.11  WHY  COMPUTER-AIDED  LOGISTICS? 

The  scope  of  logistics  has  been  previously  touched  upon.  Long-standing  major  problems  exist  in 
the  collection,  organization,  evaluation,  retrieval,  use,  and  distribution  of  logistic  data  and  information. 

On  24  September  1985,  the  Honorable  William  H.  Taft,  Deputy  Secretary  of  Defense,  established 
a  Steering  Group  to  oversee  the  implementation  of  a  DoD-ievel  Computer-Aided  Logistic  Support  (CALS) 
Program.  Since  that  time,  the  acronym  CALS  has  been  changed  to  mean  Computer-Aided  Acquisition 
and  Logistic  Support.  In  brief,  the  major  objectives  were  and  still  are 

•  Accelerate  the  integration  of  reliability  and  maintainability  (R&M)  design  tools  into  contractor 
computer-aided  design  and  engineering  processes. 

•  Accelerate  the  automation  of  contractor  processes  for  generating  logistic  technical  information 
products. 

•  Rapidly  increase  Military  Department  and  Agency  capabilities  to  receive,  distribute,  and  use 
logistic  technical  information  in  digital  form  to  improve  weapon  system  maintenance,  training, 
and  spare  parts  management. 

Note  that  the  first  two  objectives  are  directed  toward  industry  and  the  last  one  toward  government. 


The  bottom  line  is  that  government  acquisition  programs  will  be  expected  to  have  “capabilities 
to  receive,  distribute,  and  use  logistic  technical  information  in  digital  form  to  improve  weapon  system 
maintenance,  training,  and  spare  parts  management.” 

The  question  to  be  answered  is,  “Will  my  acquisition  program  meet  this  objective  with  the  resources 
and  capabilities  I  have  available?” 

To  be  useful,  data  must  be  processed  into  information.  It  is  upon  the  developed  information  that 
program  management,  design,  engineering,  logistic,  a “anufacturing  decisions  arc  based.  Analysis 
is  one  of  the  most  common  procedures  to  develop  into...  *ion. 

18.12  LOGISTIC  SUPPORT  ANALYSIS  (LSA) 

The  logistic  support  analysis  is  divided  into  3  sets,  5  task  sections,  15  tasks,  and  numerous  subtasks. 
Many  of  the  tasks  and  subtasks  will  not  be  new  because  they  have  been  applied  to  projects  for  years. 
In  fact,  they  are  considered  normal  engineering  practice.  The  major  change  has  been  to  formalize  them 
to  ensure  logistic  considerations. 

Relationship  of  LSA  sets,  Task  Sections,  and  Tasks 

Manage 

100  Program  Planning  and  Control 

101  Development  of  an  early  logistic  support  analysis  strategy 

102  Logistic  support  analysis  plan  and/or  integrated  logistic  support  plan 

103  Program  and  design  reviews 
Analysis  and  Synthesis 

200  Mission  and  Support  Systems  Definition 

201  Use  study 

202  Mission  hardware,  software,  and  support  systems  standardization 

203  Comparative  analysis 

204  Technological  opportunities 

205  Supportability  and  supportability-related  design  factors 
300  Preparation  and  Evaluation  of  Alternatives 

301  Function  requirements  definition 

302  Support  system  alternatives 

303  Evaluation  of  alternatives  and  trade-off  analysis 

400  Determination  of  Logistic  Support  Resource  Requirements 

401  Task  analysis 

402  Early  deployment  analysis 

403  Postproduction  support  analysis 


Test  and  Correct 

500  Supportability  Assessment 
501  Supportability  test,  evaluation,  and  verification 


18.13  LSA  TASK  103 

From  the  previous  list  let’s  examine  M I L-STD- 1388-1 A  LSA  Task  Number  103  in  a  little  mere  detail. 

LSA  TASK  103 
Program  and  Design  Reviews 

Purpose:  This  task  provides  for  timely  LSA  program  participation  in  the  official  review  and  control 
of  design  information,  ♦he  scheduling  of  detailed  LSA  program  reviews,  and  logistic  risk  assessments 
at  program  reviews.  Tt  also  ensures  that  all  pertinent  aspects  of  the  LSA  program  are  addressed 
as  an  integral  part  of  all  formal  program  and  design  reviews. 

Required  for:  These  procedures  for  the  review  of  design  information  from  a  support  standpoint  within 
the  performing  activity  provide  logisticians  a  mechanism  for  accomplishing  design  influence  and 
tradeoffs.  LSA  program  reviews  aid  in  monitoring  the  overall  progress,  quality,  and  consistency 
of  the  LSA  effort. 

When  required:  Program  and  design  reviews  are  generally  initiated  during  the  concept  exploration 
phase  and  are  scheduled  periodically  throughout  subsequent  phases. 

Responsibility:  Initially  the  SYSCOM  program  office  (with  assistance  from  the  TDA,  if  one  has  been 
designated)  is  responsible  for  Task  103.  During  the  demonstration  and  validation  and  subsequent 
phases,  the  TDA  assumes  responsibility  for  this  task. 

Associated  Subtasks: 

Program  reviews  Design  reviews 

Cost 
Schedule 
Performance 
Documentation 
Supportability  risk 
Assessment 

LSA  Reviews 

Task  results 
Data  exchange 
Test  results 
Recommendations 


18.14  DETECTING  TRENDS 

It  should  be  noted  that  the  logistician  is  not  only  interested  in  what  is  happening,  but  what  may 
or  could  happen  as  well.  By  detecting  trends  early  enough  he/she  has  time  to  compensate  for  changes 
and,  if  necessary,  make  major  revision  of  long-range  plans. 


Interfaces 

Specifications 

LSA 

Supportability 
Risk  assessment 


Many  situations  that  occur  within  an  acquisition  program  cause  that  program  to  be  delayed.  It 
is  not  uncommon  for  a  Navy  initial  operating  date  (IOC)  to  slip  3  to  5  years  beyond  the  original  estimate. 
The  logistician  is  the  individual  that  should  be  aware  of  the  impacts  of  acceleration  and  slippage  to 
the  acquisition  and  should  advise  the  program  management. 

For  example,  if  the  IOC  slips  during  the  full-scale  development  phase,  what  is  the  impact  on  the 
funds  programmed  by  NAVSUPSYSCOM  and  the  Ships  Parts  Control  Center  for  the  acquisition  of 
spare  parts  to  support  the  acquisition  via  their  funding  cycle?  The  magnitude  of  dollars  runs  into  tens 
of  millions.  What  courses  of  action  are  open  to  the  supply  system  to  handle  the  sum  of  money  that 
can’t  be  held  or  spent? 

Situations  such  as  this  require  very  close  coordination  by  the  logistician  for  elements  outside  of 
the  mainstream  of  design  and  conventional  systems  engineering. 

18.15  WHAT  DO  I  DO? 

Figure  18.2,  LSA  activities  in  the  acquisition  cycle,  provides  very  specific  guidance  as  to  the  type 
of  activities  normally  required. 

Note  that  the  logistical  activity  starts  even  before  the  program  initiation!  During  this  period,  which 
is  normally  taken  care  of  by  the  SYSCOMs,  definition  of  constraints  and  objectives  is  established. 
It  is  possibile  that  a  Navy  laboratory  will  be  called  upon  to  assist  in  this  function. 

The  bottom  line  of  Figure  18.2  indicates  the  types  of  funds  and  when  they  are  obligated.  Note 
that  the  typical  funding  for  logistic  considerations  ranges  from  6.1  (Basic  Research)  to  6.5  (RDT&E 
Management  and  Support).  Other  funds  included  are  procurement,  operations  and  maintenance,  military 
construction  (MILCON),  training,  etc.  All  of  these  funds  have  a  5-year  o’-  longer  cycle. 

Using  MILCON  funds  as  an  example,  it  would  be  prudent  to  consider  facilities  as  an  8-year 
requirement.  This  is  to  allow  the  definition  as  to  what  is  required,  where  will  it  be,  what  will  it  look 
like,  are  architectural  drawings  required,  site  surveys,  impact  studies,  can  the  requirements  be  combined 
with  the  potential  site’s  other  plans,  and  what  special  requirements  are  needed.  These  questions  are 
only  a  few  of  those  that  must  be  answered  prior  to  the  start  of  the  funding  cycle. 

Assuming  that  the  planning  has  been  accomplished  to  determine  what  is  required  and  how  much 
it  will  cost,  consideration  must  be  given  to  the  beneficial  occupancy  date  or  that  date  when  the  facilities 
may  actually  be  used  by  the  program.  All  of  these  elements  must  go  together. 

Failure  to  consider  the  time  factor  can  disrupt  the  entire  system.  It  can  lead  to  facilities  requirements 
not  being  met  when  they  are  required  or,  if  a  program  has  a  very  high  priority,  reprogramming  of 
MILCON  funds.  Reprogramming  of  funds  can  eliminate  needed  MILCON  dollars  from  other  programs 
to  meet  unplanned  requirements.  The  adequate  planning  of  MILCON  requirements  is  fundamental, 
yet  often  overlooked. 
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18.16  WHAT  HELP  IS  AVAILABLE? 


The  Computer-Aided  Logistics  element  of  Code  936,  (Computer  Integrated  Engineering  Branch), 
NOSC,  has  been  developing  and  applying  CALS-type  information  and  programs  for  several  years. 


The  MK  50  Lightweight  Torpedo  Program  has  been  used  as  a  testbed  for  such  applications  as 

•  HARDMAN  (HARDware  and  MANpower  Analysis)  Program 

•  TSP  Program  (Navy  Timely  Spares  Provisioning  Program) 

•  Computer-Aided  Breakout  Program 

•  CALSA  (Computer-Aided  Logistic  Support  Analysis) 

•  Interactive  Navy  Supply  System  Provisioning  Models  for  Wholesale  and  Retail  levels  of  supply 

•  Automated  DLSC  (Defense  Logistics  Support  Center)  Screening  for  acquisition  program 
There  are  such  computer-aided  tools  as 

•  ALP  (Automated  Logistics  Planner)  (in  accordance  with  NAVSEANOTE  4105) 

•  'LORA  (Level  of  Repair  Analysis)  MOD  V  Version  5 

To  maintain  currency,  active  roles  are  being  taken  in  such  CALS  activities  as 


Chairman,  Sub-Panel  for  Reliability  and  Maintainability  in  Computer-Aided  Design  (Joint 


Logistics  Commanders/ Joint  Policy  Coordinating  Group) 


Navy  representative  to  the  Air  Force  Unified  Life  Cycle  Engineering  (ULCE)  Program  Steering 
Group 


t 


•  Chairman,  Navy  Test  Technology  Strategy  Team 


If  assistance  is  needed  with  computer-aided  logistics,  contact  A1  Knight  or  Marjorie  Rezachek  of 
Code  936.  If  we  can’t  help  you,  we  know  someone  who  can. 
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SECTION  19 

FOLLOW-ON  TRAINING 


19.1  INTRODUCTION 

19.1.1  Technical  Manager  Development 

This  Center  is  committed  to  the  development  of  successful  and  competent  program/project 
managers.  Previous  sections  of  this  handbook  detailed  the  diLerent  areas  in  which  a  technical  manager 
must  be  knowledgeable  and  highly  skilled.  This  section  presents  a  road  map  of  training  and  developmental 
information  to  help  you  acquire  the  necessary  skills  and  abilities  to  become  a  competent  technical 
manager. 


19.2  KNOWLEDGE  AND  SKILLS  REQUIRED  IN  PROJECT  MANAGEMENT 


Potential  project  management  (PM)  knowledge  is  entensive,  and  skills  are  many  and  varied.  The 
technical  manager  must  know  the  science  and  engineering  used  in  the  ^velopment  task,  the  policies 
of  government  in  acquisition  management,  the  NOSC  method  of  doing  the  business  of  engineering 
management,  the  tools  to  ensure  that  what  was  envisioned  is  finally  produced  within  schedule  and  cost, 
and  personal  and  social  interactions  of  motivating  and  rewarding  task  team  members.  A  listing  of  these 
skills  and  knowledge  follows: 


PM  definition  and  responsibilities 

NOSC  policies  and  procedures 

DoO  and  Navy  acquisition  processes 

Pioject  formation 

Planning  and  control 

Budgeting  and  accounting 

Marketing 

Systems  engineering 

Human  factors  engineering 

Safety 

Team  building 
Conflict  resolution 


Product  assurance 
Configuration  management 
Contracting 
Design  lsview 
Test  and  e  'aluation 
Integrated  logistics  support 
Risk  assessment 
Warranty 
Documentation 
Negotiation  techniques 
Presentation  skills 
Writing  skills 


19.3  METHODS  TO  DEVELOP  PROJECT  MANAGEMENT  KNOWLEDGE  AND  SKILLS 


There  are  three  primary  methods  to  develop  project  management  skills:  on-the-job  training,  short 
courses,  and  long-term  academic  training.  Any  one  method,  by  itself,  is  not  the  best  way  to  achieve 
competence  as  a  project  manager.  A  mixture  of  the  three  methods  planned  over  a  period  of  several 
years  is  much  more  realistic.  An  individual  who  wishes  to  become  a  project  manager  needs  to  lay  out 
a  plan  that  uses  at  least  the  first  two  methods  to  acquire  the  knowledge  and  skills  that  are  not  yet 
possessed.  Let  us  examine  these  three  methods. 

19.3.1  On-The-Job  Training 

A  technical  staff  member  at  NOSC  usually  starts  as  a  member  of  a  small  project  team  and  deals 
with  a  more  senior  technical  member,  branch  head,  or  project  leader.  As  experience  grows,  larger  and 
more  complex  tasks  are  assigned  and  these  frequently  lead  to  becoming  a  key  member  of  a  greater 
and  more  complex  program  management  team.  The  individual  watches  the  technical  leader  and  sees 
how  this  person  goes  about  meeting  project  requirements. 

There  are  additional  opportunities  offered  to  technical  journeymen  to  take  extended  details  to 
Navy  Headqaarters  Program  Management  Offices  to  support  the  project  work  that  is  being  performed 
by  NOSC  and/or  by  the  Navy  and  industry  development  organizations.  Occasionally,  details  to 
Washington  Headquarters  organizations  are  formally  announced  as  training  opportunities  under  the 
Navy  Scientist  Training  and  Exchange  Program  (NSTEP).  When  the  Center  receives  notification  of 
NSTEP  opportunities,  these  are  distributed  to  the  technical  departments  for  interest  and  response. 

19.3.2  Short  Courses  Available 

There  is  a  wide  assortment  of  short  courses  offered  on  the  knowledge  and  various  skills  required 
of  project  managers.  These  range  from  NOSC-presented  training,  Navy,  and  other  federally  sponsored 
courses  to  nongovernment  schools,  universities,  or  privately  owned  training  vendors. 

a.  NOSC  In-House  Courses 

Project  management  course 

Contracting  officer  technical  representative  (COTR)  course 

Presentations  and  briefings 

Technical  writing 

Financial  management 

Writing  statements  of  work 

Toastmasters 

b.  Government-Sponsored  Courses 

Navy 

Office  of  Personnel  Management  (OPM) 

Naval  Postgraduate  School 
Defense  Systems  Management  College 

c.  Nongovernment-Sponsored  Courses 

Private  vendors 

UCSD  Engineering  Management  Executive  Program 
UCLA  Engineering  Management 


19.3.3  Long-Term  Project  Management  Training  Available 

Although  these  types  of  opportunities  are  rarely  used,  they  represent  an  important  resource  to 
consider  under  special  conditions.  If  a  technical  department  sees  a  need  for  trained  project  managers 
within  a  2-year  to  3-year  period,  they  may  wish  to  accelerate  the  classroom  training  of  a  selected  staff 
member  by  encouraging  this  person’s  application  for  the  Center’s  long-term  training  support  under 
the  academic  study  program.  Several  schools  have  excellent  programs.  The  following  programs  are 
recommended  in  order  of  relativity  to  NOSC  needs: 

Naval  Postgraduate  School 

Defense  Systems  Management  College 

USC  Systems  Management  Curricula 

UCLA  Masters  Program  in  Engineering  Management 

19.4  PLANNING  FOR  PROGRAM  MANAGER  DEVELOPMENT 

Figure  19.1  is  a  planning  guide  to  help  individuals  and  supervisors  be  assured  that  the  full  comple¬ 
ment  of  program  management  knowledge  and  skills  is  addressed.  We  recommend  that  this  guide  be 
filled  in  as  training  is  accomplished  and,  when  training  is  finally  completed,  that  the  technical  depart¬ 
ment  recognize  the  achievement  of  the  person  in  some  formal  fashion  (i.e.,  performance  award  recogni¬ 
tion,  assignment  to  project  leadership  role,  or  a  nonmonetary  form  of  recognition). 

19.5  ADVICE  AND  COUNSELING  REGARDING  DEVELOPMENT 
OF  PROGRAM  MANAGERS 

The  best  place  to  start  when  asking  questions  regarding  “How  do  I  become  a  project  manager?” 
is  with  your  line  supervisors  and  program  managers.  These  individuals  can  point  you  to  the  different 
methods  that  have  been  successfully  used  to  develop  their  experiences.  Many  will  comment  that  on- 
the-job  training  with  a  project  management  group  is  the  best  way;  they  will  also  recon  mend  course 
work  to  supplement  direct  experience. 

The  NOSC  Employment/Development  Office  advises  and  counsels  individuals  on  training  courses, 
academic  programs,  and  availability  of  NSTEP  assignments.  This  office  maintains  numerous  course 
descriptions  and  publicizes  in-house  courses  and  federal  government  training  opportunities;  the  staff 
will  strive  to  meet  identified  training  needs. 


